Goals for first release (June/USENIX)

Rahul Siddharthan rsidd at online.fr
Thu Mar 11 11:47:04 PST 2004


Matthew Dillon said on Mar 11, 2004 at 11:15:02:
>     You know, actually when I think about it, we do not really need to
>     have a fully working packaging system in order to have fully working
>     binary packages.
> 
>     If we use the /opt idea as a basis, then a binary package is simply
>     a tar of /opt/<packageandver> directory.  The ONLY thing we really need
>     to be able to use such a tar file is a parser for 
>     /opt/<pkgandver>/ENVIRONMENT which builds the symlinks and varsyms.
> 
>     Installation of the binary package would simply be untar'ing it into
>     /opt and running a utility that parse ENVIRONMENT and builds (or unbuilds)
>     the softlinks/varsyms.
> 
>     Most packages would have really simple environmental rules, allowing
>     the ENVIRONMENT file to be written manually.

How about dependencies -- do these go into the ENVIRONMENT file too?

There are two kinds of dependencies (rather, the same dependencies can
be viewed two ways):
 
1. Install-time: supposing I don't have gtk, and am installing the
   Gimp, the package manager should pull in gtk for me (or prompt me).

2. Remove-time (or upgrade-time): Suppose I'm trying to remove gtk (or
   upgrade it to an incompatible version), the package manager should
   warn me that this will break the Gimp.

So would the information needed for these go into ENVIRONMENT?

As for (2), I'm wondering whether if the information is missing, it
can be generated dynamically by running ldd on all dynamic binaries
This will not work when one program executes another from a separate
package, eg gv and ghostscript, but at least such programs will
usually be only "partially" broken, rather than refuse to run at all
due to missing libraries.  

Here I'm really going back to the case where I'm installing my own
tarballs without the package management system: if I used good old
configure/make/make install with your VFS ideas to install first
libfoo, then packagebar which depends on libfoo (it is my
responsibility here to be sure I've installed dependencies first),
perhaps some ENVIRONMENT thing can be automatically created for
packagebar which tells it that libfoo depends on it (and tells me that
removing libfoo, if I try to, will break packagebar).

Rahul





More information about the Kernel mailing list