Quote:

muimaster is a special case, because normally the version number isn't decreased.

The simplest (naivest) solution would be to give the whole AROS core a version number. Core components can't be updated individually.

If this is just about updating the system infrastructure, I agree it's necessary. In that case, I'd make a bounty for an "AROS Update"

Damocles - you say "don't use it" but my fear is that it'll quickly become the default method of distributing software. That's what I don't want to see. I'm not trying to be obnoxious, I just feel strongly about this. I suggest working out a good method of '3rd party' software installation at the same time.

@Kalamatee

You picked up on a general point about package managers scattering files around. I concede your point about the Amiga installer. But in general the bulk of the files were put in one drawer, and more importantly you could move that drawer wherever you want. Not where the package manager tells you it should go.

If dependencies are an issue, I'd go for a system like this.

libs
----mylibrary
------------current (link to 1.1)
------------1.0
------------1.1
----mylibary.library (link to mylibrary/current for legacy purposes?)

An AROS software installer could understand this. Finally you have an app, which is structured something like this:

myapplication
-----XML config file (points to lib versions, etc.)
-----XML files description (for un-installer)
-----x86 Binary
-----x86-64 Binary
-----PPC Binary (one or more of these binaries)

So far, so Mac-like, but unlike with the Mac, with that XML files description you could have proper uninstallation of any app that needs it. If the file exists, you could select the app in Wanderer and choose "Uninstall" from a menu. That fires up the new AROS Installer and takes care of it for you.

Chris

I have developing my own package manager for aros but it's going very slowly. Reason I'm designing my own is that I don't like GPL as core component for aros. But to get good enough package manager for aros would take only 1 day for rob or georg or other good aros programmer.

Just port ipkg, plain c, uses wget to networking and doesn't need much work to get going at aros. And does fulfill bounty...

http://www.handhelds.org/moin/moin.cgi/Ipkg

Quote:

Sorry to reply to my own post but I don't know which is the most appropriate post to reply to.

I share part of the worries with clebin but I'll try to give a more appropriate alternative here for discussion. Please read it carefully I consider this quite important as it touches to core user friendliness of AROS. I already spent more then 1.5 hours on this so forgive me the rough edges of the proposal. So please don't nitpick but try to improve the proposal where possible.

I think that what we try to do achieve with the proposed package manager are the following things:
- software installation
- software distribution
- dependency resolution
- conflict resolution
- updating of installed software
- removing unused software
What I will try to convince you is that trying to do all this by forcing one package format is not the best way to go.

software installation
There is already an old standard for this and these are the lisp based installation scripts. Maybe this system may need to have an overhaul: a shared library (e.g. installation.library) with some interface for certain scripting languages like lisp, python, ...
The library would implement the rules which software installation has to follow to fit in an AROS system. One important thing is to try to convince software developers to use the packages/NAME environment variable (1)
Also questions to the user during installation should be avoided. I prefer configurable options that can be changed from the program's settings window or program over one fixed setting determined at installation time. Maybe combined with bringing up the package preferences the first time the program is run.
Maybe in the end with a good standard package directory structure install scripts can be avoided totally as you could just copy or extract a directory at a certain place as is done like, I think, in OSX.

software distribution
Why limit software distribution to a certain file format?
I would make a library like xfd.library core part of AROS and software be distributed by any of the archive formats recognised by the library. Installation could be done automatically when a certain file (2) is in the archive.

dependency resolution
This could be handled by the installation script: It contains versions of certain needed files and a link to a place where it can be downloaded (see updating). Software distribution on CDROM could of course include all the dependencies on the CDROM and install it from the same script.
Additionally a way has to be provided to let people not remove packages on which other packages depend. This could be done by a file in the package directory: AROS/Used-By

conflict resolution
I am convinced that a package manager (alone) can not solve conflict resolution. I have a lot of experience with linux distros and some experience with windows.
Everybody knows the rpm hell of trying to use rpms from different distributions, unsolvable conficts etc.
But unfortunately for the deb and apt proponents I also had my share luck of deb hell:
- trying to upgrade a storm linux installation to the then recent debian release (lucky I had a rescue disk and a good knowledge of the linux internals)
- ever tried to downgrade a debian testing to debian stable ? don't do it!
- several problems with mixing packages from debian stable, testing and unstable
- trying to convince apt-get not to remove my KDE and/or GNOME desktop environments for some software upgrade
I probably don't have to start about windows upgrade problems .
I can only conclude that conflict should be solved at the software development level not at the package manager level. Trying to convince people we can solve this by switching to a standard package format is just fooling people.
This means that we should provide the necessary tools and methodologies in our AROS software SDK so installation conflicts are (almost entirely) avoided. This is non-trivial and should be a whole discussion on it's own.
Of course a fully fool proof system that is flexible enough will probably not be possible so some form of conflict resolution may be needed. This could then be handled by a standard file (3) that can be handled by the installation.library and for more complex cases custom scripting code in the installation script could be provided. This way more conflicts could be handled.
Unfortunately I don't have OSX experience but from the comments I got this system seems to avoid conflicts quite well. Could somebody elaborate on this ?

updating of installed software
I would decouple this from the software packaging to allow all software on a system be upgraded based on version of files not on version of packages. This could be done by another standard file (4) where it is described what files a certain package upgrades.
A distribution site can then package all this information in one file and this can be used by an updater progam to check for available updates. This way one standard AROS update program could handle all software updates (unlike on windows).
Additionally automatically sites could be added to check list of the updater if the in the directory pointed to by the packages/NAME environment variable a reference is given to the distribution site.
(OS4 AmiUpdate is an example of a not fully implemented system like this).

removing unused software
I have here the similar feeling as for conflict resolution. I do think it is an utopy to trying to force every software package to correctly indicate all the system files it uses.
So I would not try to do any automatic software removal at all. I would leave that to lower level tools that scan all software on the system and try to smart guess everything. Aditionally providing a proper backup and easy recover for the case something goes wrong.
Maybe some crude automatic removal could be done for packages that were installed as dependency of another package. But even there I would not enable this by default.
Anyway I think on modern system space problems will be caused by the multimedia data not by the software. And that should certainly be the case for AROS that should stay lean and mean.
Again I would like to know how it exactly works on OSX. Again from comments I have heard that sometimes when you run a program for the first time some installation is done of software in the system. Does these files ever get removed again ? If so when ?

To summarize I would for the following system:
* package files (any format recognized by the archive library or datatypes)
* partition.library + lisp, python, ... handling:
- system integration in AROS (mainly envarc:packages/NAME)
- dependency resolution
- conflict resolution (in limeted cases where necessary)
* updater program + software description file on web sites doing:
- scanning installed files on disk
- notifying users of updates for any software on the system
- automatically find updates for packages with the proper file in their package directory

I also want to comment on some other things I've seen in this thread:
core vs. non-core
Some people wanted to make a distinction between core files and non-core files. I would not like as the core files will change from distribution to distribution: the AROS distribution for my ADSL router vs. for my cell phone vs. for my media server vs my desktop machine.
With the system above I also think there does not need to be a difference.

use other distro if you don't like apm
I think this was one of the comments in this thread. I am really worried when I read this comment. If you see how much time is wasted on the linux community by compiling certain software for all the different distribution which in theory should be able to run each other software. I really want to avoid this in the AROS world.
I also want to avoid religious discussions like my AROS distro is better then yours because I use package manager X. This discussion should go about the included software and the integration not about the package manager, that should just work.
In the end we should come to a 'compile once - install everywhere' solution; e.g. a software developer should be able to compile one software package that can be installed on all AROS systems and be automatically distributed on other sites if wanted.

there is so much more I want to tell you about,
Staf.

(1) maybe we need to think about how to handle having more then one version of a software package installed on the system.
(2) f.ex. AROS/Install
(3) f.ex. AROS/Conflicts.xml
(4) f.ex. AROS/Update.xml

@Fats

I share part of the worries with clebin but I'll try to give a more appropriate alternative here for discussion

Actually we thinking on very similar lines - maybe I wasn't clear if you thought my solution was less appropriate.

You've gone into detail about the implementation of the Installer, which I agree is needed. Your idea of having the Installer understand multiple package formats and installation scripts written in different languages is an excellent one. It's not packages I dislike, just the distribution and management model. It's conceivable that package management could grow out of this system later on, but at least there wouldn't be a proliferation of incompatible managers and the traditional method wouldn't be relegated to second-class.

You asked about conflict resolution in OS X. Basically it works like my previous post - see the structure I outlined for the libs directory.

OS X does this with 'frameworks' rather than libraries, and you can have multiple version of the same framework installed. A symlink called 'current' points to the latest version, but an app could choose to use the earlier version. So you don't get conflicts. It's one of those NeXT Step features which is just so beautifully simple.

Other functionality is often kept within the app. That might mean a bit of duplication, but hard-disk space isn't an issue these days.

Chris

EDIT: note to self, stop editing and go to bed!

I have used Source Mage GNU/Linux for several years. It has a package manager named Sorcery. All the names of the commands have something to do with Sorcery, but just ignore that. I thought I would post these links so you could read a little about the package manager, because some of the points that have been brought up in this thread are covered in the SMGL package manager. I'm not saying we should do something exactly like this, but I thought it might help with ideas if you guys read about it.

http://wiki.sourcemage.org/Sorcery

http://wiki.sourcemage.org/SorceryCommands

Quote:

I *HIGHLY* doubt that will come to be and I am the sponsor of the bounty. I do not see the majority, or even a significant minority of the Devs cranking out .APMs only. I can see distros working to create .APMs since it will allow updating for end users. Can you honestly say you think you will see the nightly builds as APMs?

One of the biggest critisisms AROS has that it's for Devs and not end users. Too a point they are correct. APMs will hopefully be a tiny step making life easier for the end users. I'm sure there will be nasty h0rkups coming down the road as there were for RPMs, but that's the pain of growth and maturing we would have to deal with as end users. I completely understand Devs want their freedom to do whatever directory you feel is most convient to you to have a particular application in. The Devs also need to understand that most endusers like myself, don't give a rat's rearend what drawer what app goes in it as long as it works. As a end user I don't want to down load a DVD ISO either, I just want a small ISO that I can use as a base that I can do via network either updating or adding new applications/drivers after the install without pain which generally means a package manager system is needed.

Speaking to the Developers out there who still think APM is the devil, then I think it should be you who request the bounty to insure it is something you can live with.

Dammy
TeamAROS

Well, it's time for my 2 cents too.

I simply don't like packages, packages managing, setup scripts and so on. I like programs I can unpack in their drawer, and that can live in their drawer without placing files everywhere else.

And when they must do it, because they provide a library that must be installed in libs:, it should use a install script with our own installer (we already have), which should be similar to the Amiga one.

I don't like packages and I don't like "use another distribution" mentality too. Do you see packages on Windows? No, and nobdy feels the need of them: a setup.exe installer is just enough for everyone.

Packages are the geeky answer to a necessity that geeky users simply didn't have, but which allowed them to answer "I just need to launch my package manager to install programs" when a Windows user remembers them that Windoze is far easier to use.

I've already seen Linux transforming into a babele of distributions, package formats, packages written in the same format that don't work on a different distribution, and I'm simply SCARED at the idea AROS could follow this sad path.

I'm pretty sure that, before a packaging system, we need three other thing:

1. a working "official" compression algorhithm
2. a nice interface to pack/unpack compressed files
3. the will to use always, or the most times, this format

Just in these days I tried to distribute a utility written with AROS native, using its native LHA. It didn't work. Somebody suggested me to use ZIP from Linux (FROM LINUX!? DAMN HELL, I'M USING AROS, NOT LINUX! - sorry for screaming harsh).

I'm pretty sure most of us would be far happier with a WinRAR or 7zip clone, with drag'n'drop and anything that would make easier packing/unpacking software, rather than a packaging system that would not make easier installing files.

Sorry if I seemed harsh, I didn't want to do it. And everything is just IMHO. Regards,

Maybe we should just extend installer command to do that :]
It can look something like that:
installer install newBuggySoftwareFromCamelek

And it looks for it on ftp servers, that was writed in config somewhere :]
For example in:
Sys:Prefs/Env-Archive/packages/sources.config

Packages can be just simple archives :]
like tar.bz2 for example :]
and here is how I imagine that:

newBuggySoftwareFromCamelek.tar.bz2
and inside it, can be these files/dirs:

about/
packageauthor
packageversion
applicationversion
applicationauthor
description
authorhomepage
packagerhomepage
authorcontact
packagercontact
applicationlicense

scripts/
preinstall - prepares for creating new version, checks for everything, that is not checked by installer, and asks about installation mode : simple, med, adv (this can be done in installer script).
postinstall - configuration can be in GUI :], like every other step :]
cleanup - deletes temporary files created for setup only

checksum/
files.md5

data/
somefiles.txt
andothers.ogg

packages/
needed - needed to run, and here we just line after line will type what packages it needs
optional - not needed to run, this packages can be added, because then our application will have new features, that was not working without that
extra - not needed to run, only for additional things. Here we can put extra themes, or new levels for games :]

Because AROS is making day after day more portable we should think about splitting packages in few parts. For example:
data(graphic, music), binary, translations... and so on :]

Oh, and scripts can be everything that we want, only extension can describe what type it is:
postinstall.arexx, cleanup.shell, preinstall.install

(we can choose what type of script to use, everything that is supported by AROS)

But I think, that before we go to packaging, first we have to create archive.datatype, that will help much in installing packages :]
Thanks to that installing new types of archive will be independant, only thing that we will need to add will be new datatype for archive :]
And installer will be not changing every time when we will wanted to use new archive type :]

Quote:

There are 2 things which I like about package managers like apt-get: automatic updates and dependecy handling.

Quote:

There is a big difference between Linux and AROS: all AROS distros will be based on the nightly builds and the nightly builds try to mimic the directory structure from AmigaOS. So the differences between different AROS distros will not be that big.

Quote:

Problem is that Amiga-Lha isn't open source.
If we manage to port libxad to AROS then it's only a small step to unpacker like AmigaOS3.9 Unarc.

http://sourceforge.net/projects/libxad/