Packaging (Re: Goals for first release (June/USENIX))

[Rahul Siddharthan <rsidd@xxxxxxxxx>]

Here's something that I've always wanted to try doing, and it's
possible I'll have some time for that now[1], but I'm not sure if I need
some "infrastructure" support.  The idea is to be able to compile a
source tarball, "raw" (say because it isn't in the ports or the ports
haven't been updated), go through the usual configure/make steps but
type some variant command of "make install", and have the whole thing
not only installed exactly as usual, but registered in the package
database with a proper +CONTENTS file so that it can be uninstalled
cleanly if desired.

The idea is:

o  "make install" installs not to the final destination, but to some
   fake destination (like /var/tmp/ports a la gentoo linux)

   In most cases one can handle this with a "prefix", but not all
   software respects that, unfortunately.  What I'd like to see/do is
   something that makes the install command somehow believe its target
   isn't /usr/local but /var/tmp/ports/usr/local (or whatever).  Or
   maybe write a new "install" command that does just that.  But I'm
   not clear how to make this bulletproof (eg, if some installer
   uses "cp" rather than "install" to install files).  Any ideas?

   For example, there may be some "variant symlink" (let me say again
   that that's an incredibly neat idea!) to an alternative set of
   file-operation commands.  These, if you define a variable TARGETDIR,
   will first try all file operations for /path on the directory
   $TARGETDIR/path and, only if that fails, on /path.  (Much as linux
   binaries first look in /compat/linux for files and only then in /).  
   Perhaps the idea is garbage, but even if it's worthwhile, it's 
   definitely beyond my abilities :(

o  If the "fake install" has been done successfully, it's trivial to
   create a +CONTENTS file and then "merge" the files into the final
   destination (a la gentoo).  If the fake tree is on the same filesystem 
   as the final destination, the merge is very fast.

o  If the install would clobber existing files, it would warn you, and
   also tell you which packages those existing files belong to.  You can
   then take appropriate action, or force the install anyway.

o  This could also be used to "package" the base system -- something
   that keeps coming up for debate in FreeBSD -- without destroying the
   coherence of the make world thing.  In other words, it gives you a
   clean way of removing stale files, headers, etc, without too many
   changes to how the system actually works, and one could in theory
   create separate +CONTENTS files for each component in /usr/src so 
   that independent pieces (like sendmail) can be removed cleanly if 
   desired.

What do people think?  It's perhaps not realistic for a June deadline
(at least not if I'm working on it) but I thought I'd toss the idea
out anyway.

Rahul

(PS: Please don't reply pointing me to DJB's slashpackage: I know
about that.)

[1] I mean time to try to do it, not necessarily to get it working or
usable.