[PATCH] Postinstall script ordering in setup - take 2
Robert Collins
rbcollins@cygwin.com
Mon Mar 10 03:43:00 GMT 2003
On Wed, 2003-03-05 at 11:41, Igor Pechtchanski wrote:
> On 5 Mar 2003, Robert Collins wrote:
>
> > On Wed, 2003-03-05@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 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.
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
well.
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
--
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20030310/8772e630/attachment.sig>
More information about the Cygwin-apps
mailing list