Re: Package format/management ramblingss

[Soeren D. Schulze]

Richard Stallman wrote:
>     > My idea is that /bin will be something like unionfs.
> 
>     Huh?  I thought you wanted to handle /bin with packagefs/stowfs,
>     according to your suggestion of a per-user package directory?
> 
> I am not sure what distinction you are making.  Maybe we are really
> talking about the same thing in different words.
> 
> My idea is to produce /bin by unioning various directories, roughly
> /package/*/bin.  It's not that simple, of course, since there would
> be extra functionality to deal with conflicts, to do renaming of
> executables, etc.  Still, in spirit it is like unionfs, if unionfs
> is what I think it is (virtual union of several directories).

Yes, I think were are talking about the same.
I only wonder if we should implement the unionfs features directly in
our translator, that is why I got confused a bit.


By the way:  I wonder if and how we should provide other versions of
packages separately as described in my initial posting, such as:

/bin/emacs-20 -> /packages/emacs-20/bin/emacs

and on the other hand

/bin/emacs-21 -> /packages/emacs-21/bin/emacs

with either

/bin/emacs -> /bin/emacs-21

or

/bin/emacs -> /packages/emacs/bin/emacs

as Marco suggested

The problem is that one would have to configure all the programs to
expect a version number after their configuration and data
files/directories, even in user directory.  (Excuse my technical
incompetence -- I have no idea how a program usually determines the
file to look in, but because Debian people did so for some programs (I
explained), I know it has to be possible.)

/bin/emacs -> /bin/emacs-21
/bin/emacs-21 -> /packages/emacs-21/bin/emacs
/bin/emacs-20 -> /packages/emacs-20/bin/emacs

Another problem is:
A program may provide whole directories, not only files --
/share/emacs-21 for example.  But a directory may be shared, which is
good (I am not sure if it is really UNIX philosophy, but it has to be
because it is the only operating system [I am aware of] which does
so.), but it may also cause problems.  A good example is
(/usr/)share/pixmaps in Debian
(which applies this philosophy extensively), where every program can
contribute some pixmaps.
Consider Emacs provides some files for /share/pixmaps (it does not) --
providing /share/pixmaps-21 would not make sense because one would not
see the other pixmaps in that directory -- and the name would be
confusing, of course.
Consider it provides foo.xpm and bar.xpm, then we should have the
following situation:

/share/pixmaps/foo.xpm-21 -> /packages/emacs-21/share/pixmaps/foo.xpm
(Maybe foo-21.xpm would be better.)
/share/pixmaps/bar.xpm-21 -> /packages/emacs-21/share/pixmaps/bar.xpm
/share/emacs-21/ -> /packages/emacs-21/share/emacs/
/share/emacs-21/baz.data -> /packages/emacs-21/share/emacs/baz.data
(just considering)

The former pixmaps are in a shared directory, so they have versions at
their names.
The directory /share/emacs-21 is completely controlled by emacs, so it
has a version itself.

Therefore, we have to clarify:
Which package is allowed to put files where?
Should we allow other packages to put files in /share/emacs?
If we control directories in the way of permissions, we would just
append a version number directly where no package else has permission
to put files in.
But we could also check whether a directory contains foreign files and,
in that case, adjust the version number attachments.  As an
inconvenience, the directory structure could be changed completely by
installing an independent package.


I think this feature would be nice, but it causes problems everywhere
and I think it would have a minor priority.
Anyway, what do you think?

Soeren Schulze