This is the mail archive of the cygwin-apps 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 Nov 18 21:57, Achim Gratz wrote: > Corinna Vinschen writes: > > That sounds complicated in terms of usage by maintainers. Maybe I > > didn't quite grok the gist of the idea, so... given the number of > > strata, how is a maintainer supposed to know what stratum a given > > postinstall script should be? 0 and z are simple choices, but > > otherwise... Do you have something in mind which might allow to automate > > that for the maintainer? In cygport? > > Well, of course there are many more strata than needed. But I think > that anything in "Base" should perhaps be in its own stratum, maybe "b" > for instance. The idea is not to use them all, but to have something > that can be extended as needed. Some stuff is already neatly layered > (KDE depends on X depends on Base). Most of the postinstall scripts > will be on a single default stratum "(i" or whatever we are going to > decide) anyway. > > In any case, this is mainly about putting the mechanism in place or > rather to specify it. Making it usable would require support from > cygport and upset/genini. Not upset, it seems. IIUC the stratumification can firmly stay in setup' s hands with some support from cygport. Upset wouldn't even notice it. > Using hidden groups (like the non-functional > _PostInstallLast we already have) would be an obvious way to do that. Isn't that moot then? Stratum z would do it for free... > > How does the default dependency order come into play? How, in general, > > do you handle package dependencies if everything is stratumized? The > > stratum used for a script might invariable break the required order, > > unles the maintainer know *exactly* how to choose the stratum. Again, > > if it's not just simply 0 or z. > > Inside each stratum the dependency order is kept. The dependecies of > each package must then obviously all post-install on the same or a lower > stratum. "0" and "z" are indeed special since they have no or all > dependencies on postinstall fullfilled, respectively. Makes sense. And the naming convention? No chance for collisions with existing scripts? Btw., the MTA discussion has shown another problem. The problem is that preremove/postinstall scripts are run on package update as well, because setup doesn't allow to differ between install, update and uninstall. Do you think it's complicated to allow to differentiate this in setup, so we can, for instance, handle this kind of package collisions better? > >> That would be the project "Cygwin", right? > > > > That would be "cygwin-apps". > > Ah, I thought I was supposed to chose a project from the list. cygwin-apps is in the list. All projects using the cygwin-apps CVS repo are subsumed here. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpOG_879pymo.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |