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 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.

>  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

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.

So: I see what you mean by granularity but script dependencies can also
be circular. 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

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).


GPG key available at: <>.

Attachment: signature.asc
Description: This is a digitally signed message part

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