This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] Postinstall script ordering in setup - take 2
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Robert Collins <rbcollins at cygwin dot com>
- Cc: cygwin-apps at cygwin dot com
- Date: Mon, 10 Mar 2003 09:30:02 -0500 (EST)
- Subject: Re: [PATCH] Postinstall script ordering in setup - take 2
- Reply-to: cygwin-apps at cygwin dot com
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.
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...
|\ _,,,---,,_ 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!