According to Hubert Feyrer:

My apologies for not entering this discussion earlier...

>> I myself use /usr/local/<pkg>-<vers>, e.g.:
>> > /usr/local/mtools-2.0.7
>> > /usr/local/X11R6
>> > etc.

>> Hmmm, sorry for only dropping in now, the above structure is great for
>> humans, but what on earth is going to do to the poor shell that has to
>> parse the $PATH etc. to make the system work? What will the impact on
>> memory be, etc?

>I assume you understood that the users (and that's what we act for here :-),
>and with them their shells, don't have to include all those dir's
>bin-subdirectories into ther $PATH, but only some common bin-dir
>(/usr/local/bin), which contains only symlinks.

[deletia]

>But serious folks: i remember the precious discussion (to be honest: flame-war
>fits better!) about packages on the amiga-list. Right now we seem to be at a
>point at where we've settled on the concept of packages being in
>/usr/local/<somediryettoname>/<pkg> and binaries, man-pages etc. available
>through symlinks to /usr/local/bin, .../man, etc. If someone has reasonable
>arguments against it, please speak up *now*, tell us and possibly tell us a
>other (better) solution!

Better solution (IMO) is for a "package" to contain a bill of materials
(BOM) which determine the location and version(s) of the required files
and Unix facilities.

The BOM is extracted into a package directory, which acts as a repository
for that package/version, and any objects which are specific to that
package, but have been superseded but another.

A package can then be installed directly from an archive by a program
which parses the BOM, installing as needed and preserving any objects
which may otherwise be destroyed. The installer consults the BOMs of
other packages to resolve where conflicting objects are to be
preserved.  If possible, the objects should contain some "hint" of
which package they belong to - pretty easy with files in general, but a
PITA with special files.

The installer should keep track of conflicting objects by recording
them withing the package directory.

A de-installer can either delete all objects belonging to a package,
restoring previously destroyed objects; or it can simply squirrel
away the package temporarily by moving all its objects inside the
package directory, etc.

It's best to extend the package paradigm to the base operating system
as well.

The significant advantage of this is that PATHs don't get intractible
or unneccessarily complex, and symlinks are minimized (yeah!), further
reducing the system overheads.

The onl;y disadvantage which I can see at this point is that all package
BOMs need to be on-line for this to work - and in the long run, some
overhead is incurred when packages are so as to include the package
identifier in all possible files.

>Having just symlinks in .../bin, you can have two versions of a package
>simultaneously on your disk, without much hassle when exchanging. I e.g. had it
>several times that i installed new version of software, then hat do back down
>to the previous one due to errors in the new version. If you keep binaries in
>your bin-dir, you overwrite the old version when upgrading, with no easy way to
>back down.

The de-installer/installer described above would handle that easily.

-- 
Bernd Felsche {speaking for himself}
MetaPro Systems Pty Ltd, 130 Fauntleroy Avenue,
Redcliffe, Western Australia 6104
Phone: +61 9 479 3722    Fax: +61 9 479 3720