Re: Package format/management ramblingss

[Soeren D. Schulze]

Hello,

I would like to tell you just my opinion about package management.  It  
exceeds the topic a bit, but it is a part of the main problem I am  
going to deal with.

I did not know who to reply exactly, so I am just writing to the  
list ...

Translators on /bin and /sbin directories are a good idea, which could  
be pursued some further.
It would enable some *very* interesting features:

Currently, the file to execute entering a command is determinded by  
PATH, which is already nice because it enables users to have their  
local installations of programs.  Nevertheless, not all programs are  
smart enough to work properly in a foreign environment.  dpkg is, for  
example, not smart enough to install anything in a non-/ environment in  
the ``regular'' way (we need debootstrap for this).  But even if it  
was, the problem of conflicting configuration files would occur.  Of  
course well-written programs support user-specific configuration files,  
but they just set the limit from 1 to 2 configuration files.  I know  
people who use two user accounts just because they have two e-mail  
accounts but their program supports only one.  It is the same problem  
if you have a (physically :) portable computer and work in two separate  
networks with it and need independent configurations but do not want to  
install a new system for each environment.
Yet another problem are conflicting versions.  In Debian, for example,  
two different installations normally conflict.  As a compromise,  
unstable development versions, for example, are provided as separate  
packages.
Every problem of this kind is solvable, but a solution does not exist  
in all cases; so a *general* system-wide and program-independent  
solution would be desirable.

What I now suggest is a step away from a directory tree that represents  
the physical harddisk with its partitions and their filesystems, as  
UNIX, Linux and finally the Hurd aim to do anyway. But I do not just  
say ``directory tree != filesystem'', I say ``system != environment''.
What that means:
A general solution of the mentioned problems would require a feature  
quite close to symlinks, but far more intelligent:

1. Symlinks handle directories just as files; an intelligent solution  
would ``merge'' directories:  If you have, for example, the file foo in  
a/ and the file bar in b/ and merge these directories, you have the  
files foo and bar in the virtual directory.
2. Also desirable would be the feature of ``preferring'' symlinks,  
which especially becomes interesting with the feature of directory  
merging:  You can link two or more files on one, where you can specify  
the file to ``prefer'', which is actually accessed.  If you have the  
file foo respectively in a/ and b/ and prefer a/, you get the file foo  
in a/ when you access foo in the virtual directory.  The other files  
could be handled as a kind of file versions.  A question would be the  
behavior if you do not have access to a file you prefer.

The more important question would be the technical realization.  A  
server could do the job, but it would be probably slow.  If we ever  
write a special FS for the Hurd, we should include this feature.

You could, as every user else on your system, act in a kind of chroot  
environment and compose your own user-specific directory tree!
You could, as an administrator, have as many environments as you want  
running at the same time; if your programs conflict -- no matter, just  
prefer one.  You could have different configurations without replacing  
the rest of the system.
Now you recognize the need of a dependency handling system:

1. A package manager would have to manage the chaos that exists on the  
filesystem.
2. Something deep in the system would have to control your preferences  
not to conflict (combining the shared data of foo-10.0-beta with foo- 
5.0-stable and libfoo-4.1 would cause trouble ...).  This could be a  
kind of file attributes, but it would be more elegant having a special  
place in the filesystem, if we hack a new one.

Well, those are just visions, so please comment them as such.

Soeren Schulze