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]

Re: [RFC] incremental rebase


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]