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. Using hidden groups (like the non-functional _PostInstallLast we already have) would be an obvious way to do that. > 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. >> 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds