This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 and
> > and B (containing and  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 should run
> > before, but should run before  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

> 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 (, 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...
      |\      _,,,---,,_		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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]