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 Mon, 2003-03-10 at 16:18, Igor Pechtchanski wrote:
>
> > > 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...
>
> For some value of installed :}. Actually package dependencies are fairly
> strict: we can't run any files from package B until package A has run
> it's postinstall script (i.e. is fully installed). This appears
> isomorphic to scripts to me.

I see.  Then I misunderstood.  You are right, they are isomorphic.  All we
have to do then is honor these dependences.
Although how it is possible to run all the scripts from package A *before*
all the scripts in package B, *and* to run all in B *before* all in A (in
case of mutual dependence), still escapes me.

> > I agree that "redundancy leads to inconsistency", and specifying script
> > dependences will also require specifying the necessary package
> > dependences.
>
> (*)
>
> > > 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... :-)
>
> I think 20 is a huge exaggeration. I can think of -at most- 3 that we
> need. I allowed for 5 above to give some elbow room.

What about the "common" packages?  If a package maintainer has to split
his package into a few parts just to allow proper dependences, this
*could* lead to an increase in the number of dummy/helper packages...

Note that I'm not arguing for in-script dependences at this point, just
clarifying my previous message.

> > > 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.
>
> I'm not worried about preferences: I'm worried about robustness.

Fair enough.  Frankly, I can't think of a real-life situation that would
require the intricate inter-dependence between packages that I gave as an
example earlier, so it probably is a moot point anyway.

> >   It could be specified using
> > helper packages, but generating them by hand is error-prone and easy to
> > lose track of.
>
> (*) As oppossed to syncronising the needed packages with the needed
> scripts, and ALSO tracking changes in the script names?

Probably not.  Both are nasty.

> > If the use of package dependences were mandated
>
> No if here. Package dependencies ARE mandated TODAY.

I meant "if the only dependences allowed were package dependences" (at
that point I was still arguing for in-script ones).

> > , maybe we
> > need a tool that would convert script dependences to package dependences,
> > and generate the necessary helper packages...
>
> Thats an interesting idea. It allows you to follow your preference,
> shrinks setup.exe's code (no need for setup to know about script
> dependencies, only the package DAG), and would be useful.
>
> Rob

Actually, another use of this tool would be to verify package structure.
A branch of "upset", perhaps?  Just thinking aloud here...  It's a big
project, though, and I won't be able to get to it in the near future, so
if anyone wants to take over on this one, go ahead -- I'll gladly share
whatever ideas I will have accumulated...
	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