I like the idea of an install language, install scripts could be more readable, but creating such a thing its a huge and long work.

:vik1: Ahem... ok.. bothering you guys once again. I just found out one thing you may find interesting to read:

http://ing.light-speed.de/

It's the InstallerNG, the AOS4 installer. I'm not much into writing a real "install language" but from the informations on this site we can have some further ideas.

Ciao,
Fred

Hi guys, thanks Coolcat for creating another package manager thread. Thanks for posting more opinions and thoughts Blippy.

The slackware installer seems interesting but the dependencies issue it raises makes me think that in the end is not much more than a normal archiver that depacks files simply rebuilding the same the path structure stored in the archive. In my draft I was (in a poorly written english anyway!) describing that the archive itself should be built saving the directory structure too (so that anyone can even skip the installer and do all by hand if necessary).

The more I think about the AROS policies the more I'm worried Blippy. I totally agree on the need of having very clean policies, it definately helps building an installer and even more helps not ending up with the mess you can easily see in the Linux paths (12 different branches in a path or more... sounds a little bit excessive). :uh:

I know it's not a real issue those days in which aros is still getting his vital functions being fine tuned but even an eye on the multiuser features may help... not easy to build policies not keeping single/multiuser env. in mind.

To add some more spice: either I don't want to start messing about with environment variables and suchlike! That's why I'm thinking of adding some "post-install" tag to the package.xml file so that the config tool can be automatically launched at the end of the install process. But maybe there are better solutions. Comments on this are verrrry welcome.

One last thought on the compression technology: we all know the most common ones nowadays and should be not that hard to use whichever we like. I would start by adding the .zip one (the most widely available) to the manager core and the others at a later time (.lha still is in my favourites list). Maybe the other ones can even be built as datatypes the manager can use instead of building them in the package manager itself...

Ciao and thanks for the comments,
Fred


PS to Coolcat: more tags can of course be added and the ones you wrote down are no problem at all. About the "classic" Amiga installer on AROS I'm going to study how it really works as soon as I have some time to turn on my Linux/AROS box.

The problem I see is no accounting for reverse dependancies and no provisions for uninstallation. Other than that, workable.

[EDIT] sorry, now I see it's in there.

I had mentioned before that the Slackware package approach had interesting possibilities.

As I think about this more, the more I like the Slackware philosophy. AFAIK, the basic idea is that a package is a compressed file with an installation script hidden inside. The package gets uncompressed to a fixed location, and the installation script is run. Simple and neat. What it doesn't solve is the dependency issue.

This isn't necessarily a bad thing - and we'll probably be doing ourselves a favour by separating out the concerns. I can imagine, for instance, cutting a CD containing all my favourite AROS extras (let's say, from TAA [The AROS Archives]), and installing the bits I need using something like
installpkg foo.tar.gz

I also think AROS needs to start thinking about policies, i.e. where packages sit, and other package administration issues. I notice, for example, that there is a directory called Tools, and a directory called Utilities. What's the difference? They seem like interchangeable words to me. This is the kind of issue that needs resolving.

We also need to think about
* "flat versus deep" - should all packages just go in Extras, one level down, or should there be a more hierarchical structure, a la TAA
* "central versus decentral" - should all executables go in a bin directory (decentral), say, or should a package keep to its own package directory (central)? What about configuration files/settings?

Let's say I want to install Michal Schulz's lcdtest package from TAA. I want to be able to
installpkg lcdtest.i386.lha
and then just type
lcdtest (or whatever the underlying executable is)
to do the test. I don't want to start messing about with environment variables and suchlike. Users want to install, and go. Admittedly, this might not be possible in all instances. AROSTCP, for instance, is always going to need some setup for the IP addresses, DNS, and suchlike. That's just a fact of life. I'm hoping that that is an execption, rather than the norm, though.

We might also consider what compression technology we are using: zips, or lha. Setting policies like this helps simplify the tools.

hi,
i would like to hear opinions about this:
http://fred.butterodargento.it/AROS-PackageManager.htm

sounds it could be a good approach!

i know there are other thinking in the subject, so, here it is.

regards,

ps: it could have other fields like repository url, size etc (course)

ps2: could we make a mixed approach of this new layout with the allready coded aros installer?!?!?

just to start the discussion! =o)