Re: Package format/management ramblingss

[Soeren D. Schulze]

Richard Stallman wrote:
>     > However, having some sort of per-user customizability might be
>     > nice too.  Each user could have a package subdir of his home
>     > dir.
>
>     Does this mean the user ``contributes'' packages to the system?
>     Or does it mean the system looks different for each user, which
>     accords to my idea?
>
> I mean it could look different for each user.  My scheme didn't
> include that, but that's what I think you are suggesting, and it
> seems like a good idea.  Thanks.
>
>     By the way:  I meanwhile heard about unionfs, which is probably
>     what I considered.
>
> 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?

As far as I can see, this would replace my idea of a chroot environment
completely:
When the packagefs/stowfs translator gets a query, it first looks up
the user name and checks ~<user>/.pkgpref.  A sample file could look
like this (a bit Lisp-style):

(LookupPath /packages)
(LookupPath /home/<me>/packages)
(Package emacs
(version >= 21.*.1) # nonsense example for demonstration
(release = stable)) # preference with minor priority because mentioned
                    # later

This would fit perfectly in a file name called
address@hidden@release=stable.  If exactly this file is not
available, it would prefer address@hidden@release=testing
instead of address@hidden@release=stable, because the Version
condition is mentioned earlier.

But there is another problem: A *very* few programs consist of a single
file, so this file could not be just the file which would appear in
/bin.  Instead, it could be a directory which contains all the files
it ``exports'':  bin/emacs, (share/)doc/emacs, ...
When you request /bin/emacs, it therefore has to search
/packages/*/bin and /home/<me>/packages/*/bin -- excluding the
directories it does not prefer -- for the file `emacs', which is very
inefficient.  As a solution, it could use a hash tables -- created
either at any change of .pkgpref or on-the-fly for any already found
package; in any case, it should be saved on disk on shutdown.  It is
not the perfect solution, though.

Yet another aspect is the handling of dependencies.  Therefore, every
package could have its own dependency file, which is syntactically
similar to the preferences file:

# obligatory
(Require glibc
# all conditions have to be satisfied
(version >= 2.3.2)
(release testing))
# just a preference of the package
(Suggest xfree86
# condition handling as for preferences
(version >= 4.2))

This would slow down searching significantly, though, so even
on-the-fly hash table creation could be too slow.

An intelligent server would now have to do the following:
- do the lookup as efficiently as possible
- automatically prefer packages with solvable dependencies, even if not
 preferred by the user -- maybe send a mail with a warning

Some criterias to prefer packages are:
- version (allowing flavors as in Debian)
- expected stability (as in Debian)
- name of the (human) compiler/packager / ``origin'' (as in Debian :)
- source directory (i.e. where the symlink points to)

Wildcards should be allowed, too, possibly even regexps.

What do you think about it?

Soeren Schulze

PS:
Sorry for the duplicates of the last message.
I should change my mail client.