Is this basically a replacement for the Installer, but with RPM/APT database, compatibilty and updating features? If so, it should make software installs, updates and uninstalls a lot easier for OS4 users - nice Would there be the same flexibility for setup as when using Installer?

Last edited by alx on 21-May-2005 at 10:16 AM.

_________________

I dearly hope that this will be included as a contrib in OS4 final. A package manager, coupled with a GUI that updates a database with available apps, is great for all users alike that's looking for for some basic apps for their Amiga. And it's a great argument for using the Amiga, finding freeware/oss applications to get you started should, once the GUI is in place, be effortless even for the most clueless user.

@Wiffy and others

Cheers, this is one of the best pieces of AOS software news that I've heard about in a long time.

Yes, thats precisely what it does.

I know of one software writer who was working on something a bit similar, I dont know how far he has got, but hes an excellent gui writer. I hope he takes a peek and incorporates his work - or if his stuff turns out to be better - that we join him.

What it doesnt do in the public version is identify dependencies and whatnot. We still need to get broad agreement on how to maintain depedency information on file stores.

Of course if the OS4 team think its up to it, they can use it.

Cool, I`m looking forward to trying it out. Hope it becomes as efficient as APT GET is in Debian. I`m sure it will bring a huge boost to OS4

_________________
Swisso Bournemouth A1XEG4 1.3Ghz 7457 CPU

A-Eon X5000/40

@ Wiffy

Quote:

Of course if the OS4 team think its up to it, they can use it.

In fact, we already had discussions in the past about a package system, but never got to a definitive conclusion and decided it would be thought about after "when it's done".

I brought the topic of APMS up on the developer mailing list. This definitely sounds like something we've been waiting for since a long time.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

If this is going to be anything like APT and Synaptic it's going to be so Great.
Have almost never had any problem installing anything with it, and its easy to keep your computer up to date.

This will really be a huge hit if it becomes as good as APT/Synaptic.

Great. It could also be used to update critical things. Sky is the limit.

Coder

_________________
Can't get enough of me?
The Bucket Diary Blog
The Bucket Diary Twitter Account

Hmmm, this sounds very much like another (as yet unreleased) tool I could mention....

_________________
Simon

Comments made by me on any public fora are not representative of, or on behalf of, any company I may have, or assumed by the reader to have, any association with.

Any comments are a personal opinion, and should be accepted as such.

This sounds excellent. I have a bit of a manual way of keeping my system up to date but this should prove to be a little more efficient

FuZion.

@EntilZha

OT:

Quote:

it would be thought about after "when it's done".

Is there a life after "when it's done"?


Back on topic: The APMS System sounds very useful, nice work guys!!

_________________
www.amiga4ever.de

As Rigo said theres another system, which hopefully we can merge, or bakeoff. Either or, its something we need and at least one of the tools will be perfick.

This sound really good. One thing though, kpackage needs some time to scan
through the source-list. Will this program use a similar system? I'd like to
see it being a bit faster if possible.

Quote:

Yes, thats precisely what it does.

impressive Wiffy, most impressive !

_________________
"The system no longer works " -- Young Anakin Skywalker

Quote:

This sound really good. One thing though, kpackage needs some time to scan through the source-list. Will this program use a similar system? I'd like to see it being a bit faster if possible.

Well, there are a couple of factors in this, but bear in mind package management is something that STILL hasn't been 'done 100% right' IMO..dependencies being the big problem generally.

As regards kpackage- I THINK that does all communication over the network, but may be wrong as I don't use it...even when a 'package database' is on local disk, processing more than just the file name for 10,000+ packages (such as Linux has now) is going to take time.

The best soultion is usually a compromise, perhaps something like BSD ports or Gentoo portage does- a scheduled or manual information sync to remote system(s), and then use that information locally. Obviously, the package information to be stored as well as the underlying disk and filesystem efficiency is going to play a huge part in how fast something like this is..

I think this is something that would be very useful to OS4 users, but I think the big question is regarding adoption success...and I think the only real way for something like this to be globally adopted is to hopefully be refined enough to include as part of the OS4 final CD, or if Hyperion were to push it (ie, make all contrib code adher to this format).

As for other efforts, there pretty much always are...it's not anything to get upset over, unless the initial project was being designed together from the start. Taking a look at each of the two and making comparisions and/or merging the projects may be useful.

_________________
Are we not done with the same silly arguments and flames yet??!

@wegster

Ever tried the Debian package system? Imo, that is the one that works best, and is as close to 100% as possible, if not there. dpkg together with aptitude is, as far as I can tell, unrivaled in the package management department.

_________________
It is not the critic who counts: not the man who points out how the strong man stumbles or where the doer of deeds could have done better. The credit belongs to the man who is actually in the arena." Theodore Roosevelt, speech in Paris, 1910

Quote:

Ever tried the Debian package system? Imo, that is the one that works best, and is as close to 100% as possible, if not there. dpkg together with aptitude is, as far as I can tell, unrivaled in the package management department.

Yes, but it's been a fair while since then, only recently using it again with Debian on the A1.
I've worked on code to work very closely with RPM, including dependencies, plus numerous years of dealing with RPM, pkgadd, swinst, plus portage and ports systems. I'm sure there are a few other obscure ones as well I'm missing though

I'll try to spend some more time on Debian for a bit, and see how it fares versus BSD ports and Gentoo portage (both very similar and handle both source/compile as well as binary packages).

I think a big part of the success or not of a system like this may be in the ease of use to someone writing an installer/datafile for the system. Let's face it, there is a HUGE range of skills and patiece in people doing ports and new AOS software, and it would be a shame to NOT use package management because it's difficult for a developer to grok the format of what's needed.

Something that could be effective and fairly simple for the initial attempt (generally ALL pkg mnagement systems take several iterations to 'get it right.'):
1. Package name
package version
supported OS versions
home page/authoritative source
libs it supplies if any
libs required if any (including versions)
other programs required if any (including versions)
optional programs or libs

That's the basics of what are needed anyways.

Note that versions should likely include , =, == syntax, and this is really where things can get messy. Program A requires lib D, version >= 44.0. Program B requires lib D == 43.1. What options you present to the user become critical here. Something like the MS way incorporating interfaces and interface versions (ala COM), is IMO simply too complicated to get into at this point, as I'd expect it to be difficult to 'force' adoption, especially for older software packages...so best bet would be to initially 'KISS' it..

Using OS4 depot as a source for info would be excellent, if the required format could be pushed, and the 'info file' retrieved easily by such a program for instertion or updates into it's own 'database' of program info.

I've got a busy weekend and then off to CA next week, but will definitely take a look at this-

Wiffy- is there anything written up as far as backend package info/script requirements?

_________________
Are we not done with the same silly arguments and flames yet??!

I can tell you this, I'm managing a host of rpm-based machines.. numerous machines, and yes, there are some tools that help a bit wrt dependencies. However, a single machine using that system causes more problems and headache than 50 using the debian package system.

apt-get install bla.. never a failed dependancy.. apt-cache search bla.. it's just wonderful. Anyway, I digress. Getting something similar for AmigaOS is super, now if we could unite behind a way to make this uniform across *all* packages. I'd like to see the new readme-format of AmiNet set the baseline here.

Perhaps 2-3 people intimately familiar with other packaging systems and how they manage this part could get together and talk about this?

_________________
It is not the critic who counts: not the man who points out how the strong man stumbles or where the doer of deeds could have done better. The credit belongs to the man who is actually in the arena." Theodore Roosevelt, speech in Paris, 1910

This is just great! Finally its (almost) here..

About debian v.s. RedHat etc. I have to agree with Guru. And besides theres about ten times as many packages in debian as in the "official" rpm base at RedHat. Suse also got lots of packages, or atleast so I've heard.

Gentoo's portage still kicks every ones ass. (in the Linux world)

Quote:

I can tell you this, I'm managing a host of rpm-based machines.. numerous machines, and yes, there are some tools that help a bit wrt dependencies. However, a single machine using that system causes more problems and headache than 50 using the debian package system.

Don't get me wrong, I think RPM is _entirely_ broken, I was just mentioning it as I've got unfortunately too intimate a knowledge of the way it 'works' (when it does), and it's shortcomings!

_________________
Are we not done with the same silly arguments and flames yet??!

This is a great idea! I can't remember how many times I've downloaded something from Aminet and the readme just said "needs foobar.library 44.1" with no indication of where to get it from.