[MLton] straw-man packaging proposal

[Cynbe ru Taren]

Stephen Weeks <sweeks@sweeks.com> writes:

> I've been thinking a little about a packaging system for MLton using
> MLBs and thought I'd throw out a straw man

I don't want to rain on anyone's parade here, but I really
do believe this is one wheel which should be re-invented
only with great trepidation.

(Arguably) the hardest problems in software tend to be those
involving interfaces of various sorts, and a packaging system
winds up being The Interface To Everything.

Meaning that a tremendous amount of the design and implementation
wind up being learned the hard way, through bitter experience with
unexpected snafus.

Designing a new package system means either learning from existing
package systems -- or repeating their growing pains all over again.

E.g., three issues not touched on in the straw-man proposal but
treated centrally by Debian's package system (frequently named
one of the best):

 o  Mutual exclusion of packages.  You don't want to have two
    smtp daemons running at once, say.  Debian has 'conflicts'
    fields in packages for this.

 o  Packages which can benefit from, without requiring, other
    packages.  E.g., a graphics package may be able to take
    advantage of a postscript printing facility on systems
    possessing it,  but still be perfectly usable without it.
    Debian has 'suggests' and 'recommends' to handle flavors
    of this.

 o  There may be work that needs doing before and after both
    package installation and removal, in general.  Debian has
    slots for arbitrary pre-inst, post-inst, pre-rm and post-rm
    scripts to handle this stuff.

If an existing package system is not to be adopted to do the
lion's share of the work for MLton, then an existing best-of-breed
packaging system should be carefully studied, the key units of
functionality identified, and an argument made why, in each case,
MLton does not need that functionality, if the decision is made
not to implement it.

(An additional advantage of the Debian packaging system is
that it is open source and relatively well-documented.  A
skim of http://www.debian.org/doc/debian-policy/ might give
some impression of how much stuff comes up in packaging, and
one set of solutions to those problems.)



I -will- toss in a feature request:  Universal undo.  It is
-really- discouraging to attempt to install (or remove) some
packages and have the system wind up totally broken with no
simple way to backtrack.   User interface experts claim that
the ability to undo mistakes cleanly is core to making users
comfortable with a system.  It gives a feeling of confidence
and safety, vs the feeling of living in a house of cards which
may collapse at any moment for any reason.

(At present, in Debian, I implement this in ad-hoc fashion by
running a mirrored raid and de-activating one disk before doing
a signficant package system operation:  If it flubs up in some
obvious fashion, I can revert to the old disk image.  Unfortunately,
it sometimes flubs up in inobvious fashion, say by disabling the
DNS primary server, which doesn't become evident until the secondaries
time out...)

 -- Cynbe