cfengine and package management

[Russell Davies]

There seems to have been quite a bit of dialogue recently concerning
package management, personally I feel that a file-based approach would
better suit cfengine and could be done in such a way that it is the
same approach across operating systems without confining oneself to a
particular package format. I also find packages are annoying because of
the creation overhead they incur.

http://cr.yp.to/slashpackage.html seems to be very well thought out
in this respect and allows multiple versions of the same package to
co-exist, a feature which most ``/usr/local'' type arrangements
don't, it also addresses the shortcomings of most other package
based efforts. http://multivac.cwru.edu/spf/ is an initiative to aid
in setting up such hierarchies.

(I realise gnu stow attempts to solve this problem, but it allows the
use of the library aggregate directory when compiling new packages,
/package doesn't have the concept of a library aggregate directory --
you shouldn't need to use $LD_LIBRARY_PATH to run a binary, ld's --rpath
could be used with /package instead)

I envisage my NFS server(s) having package hierarchies like;

/fs/package/linux-i386
/fs/package/linux-i486
/fs/package/linux-i586
/fs/package/linux-i686
/fs/package/linux-sparc64
/fs/package/sunos-5.6-sun4d
/fs/package/sunos-5.6-sun4m
/fs/package/sunos-5.6-sun4u
/fs/package/sunos-5.7-sun4u
/fs/package/sunos-5.8-sun4m
/fs/package/sunos-5.8-sun4u
/fs/package/sunos-5.5.1-sun4u
/fs/package/freebsd-4.4-release-i386

(there would of course be a lot of overlap between various target hosts
and sharing of packages between os versions is something cfengine could
control using class rules, link or don't link)

The problem is usually that most people do direct nfs mount of the
corresponding architecture directly into /package on the client machine
(or /usr/local/) which means you don't then have the option of symlinking
from /package to local filestore if you so choose.

cfengine could manage the mounting of the relevant /fs/package/
hierarchies (there may be more than one per client) onto the client
(they can be mounted anywhere, it shouldn't matter), then symlinking from
/package into the nfs mounted filesystems (as well as possibly others)
and the creation of the symlinks in /command to the relevant binaries
under /package.

A few drawbacks that I can see;

- you have to be very careful when compiling not to link to libraries outside 
  the /package hierarchy (except libc and ld, you can also put these
  under /package control though) 

- you need to keep old versions of packages around forever, unless
  you check every binary under /package and ensure nothing links to 
  to the libraries of the package version you're about to remove
  (the version number of the package library is hardcoded by ld).

Under cfengine control I think an arrangement as above would be great,
no package formats to fiddle around with and new packages can trivially
be installed and distributed, additionally existing packages could be
modified with the usual filesystem tools.

Comments welcome.

r.