This is the mail archive of the cygwin-apps@cygwin.com 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] |
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 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>.
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] |