Re: [PATCH] Postinstall script ordering in setup - take 2

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On 10 Mar 2003, Robert Collins wrote:

> On Wed, 2003-03-05 at 11:41, Igor Pechtchanski wrote:
> > On 5 Mar 2003, Robert Collins wrote:
> >
> > > On Wed, 2003-03-05 at 08:19, Igor Pechtchanski wrote:
> > > > On 5 Mar 2003, Robert Collins wrote:
> > >
> > > > > Using the packages as dependencies we can build the same topological
> > > > > tree based on the packages that will end up as installed (Because we do
> > > > > know which package has which postinstall script).
> > > >
> > > > Yes, but using scripts is more fine-grained.
> > >
> > > What granularity is needed that isn't present today?
> > > Rob
> >
> > Well, one example I could think of off the top of my head is mutually
> > dependent packages.  Package dependences can be circular, script
> > dependences cannot.
>
> Sure they can. All it takes is two maintainers marking the other script
> as a requirement.

Oh, of course you can *have* circular dependences, but you can't *honor*
them.  Script dependences mean that some script has to be run before the
other.  It's a partial order.  Package dependences are less strict, in
that they don't require package A to be installed before package B is
installed, only before package B will run...

> >  Suppose we have packages A (containing A1.sh and
> > A2.sh) and B (containing B1.sh and B2.sh).  Currently we can specify that
> > A should be installed for B to work, *and* that B should be installed for
> > A to work.  However, we can't specify, for example, that A1.sh should run
> > before B2.sh, but B1.sh should run before A2.sh.  We could say that
> > postinstall scripts in mutually-dependent packages will run in an
> > indeterminate order, but we'd have to run either both B?.sh first or both
> > A?.sh first.  Even combining them into one package will not ensure
> > postinstall script ordering.  The only solution I see, aside from adding
> > script dependences, is a bunch of almost-empty helper packages...
>
> I don't see that as a particularly good or bad solution. I think that
> leveraging package dependencies is better from a couple of points of
> view:
>
> 1) It reduces the 'do n things on install' to 'do 1 thing on install'
> that must be prevalent to have mutually dependent postinstall scripts in
> the first place.
> 2) It can be precalculated *before* downloading packages. With
> postinstall script dependencies, there is *no* guarantee that the
> package containing the needed script will exist. At least with package
> dependencies we can warn before downloading that a required package
> doesn't exist.

I agree that "redundancy leads to inconsistency", and specifying script
dependences will also require specifying the necessary package
dependences.

> So: I see what you mean by granularity but script dependencies can also
> be circular.

See above.

> I suggest that the pragmatically needed granularity does
> exist at a package level, given that only a few (< 5) such core packages
> are needed, and that for larger packages (i.e. tetex) the common idion
> amongst rpm and dpkg distributions of a -common package will serve us
> well.

Most likely.  However, anything that increases a newbie user's confusion
upon install is not a good thing, IMO, and seeing 20 dummy packages is not
going to be very enlightening... :-)

> Which brings me back to : what is remaining about script dependencies
> that makes it more suitable as a long term solution? (And memo to self:
> check code to ensure that we sort generate a DAG of postinstallscripts
> by packages today).
> Rob

It might be a matter of personal preference, but if a postinstall script
depends on some other having been run (base-files-mketc.sh, for example),
I'd rather specify this in the script itself.  It could be specified using
helper packages, but generating them by hand is error-prone and easy to
lose track of.  If the use of package dependences were mandated, maybe we
need a tool that would convert script dependences to package dependences,
and generate the necessary helper packages...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha at cs dot nyu dot edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor at watson dot ibm dot com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune