[RFC] incremental rebase

Achim Gratz Stromeko@nexgo.de
Wed Nov 19 11:38:00 GMT 2014

Corinna Vinschen writes:
>> 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...

In both cases the use of the prefix is what decides the stratum.
Arguably that could be made explicit in setup.hint instead, but that
would require extension of the data format and changes to tools that use
the data.  As long as we're manually assigning those strata (or farming
this out into cygport) then no such support would be needed indeed.

ANother question: setup is used by other projects it seems.  How do we
ensure they either agree with us or are unaffected by this change?

> Makes sense.  And the naming convention?  No chance for collisions with
> existing scripts?

The Cygwin Package Search says that no such postinstall scripts
currently exist, so I'd say we're GTG with the prefix idea.

> 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?

Setup always does a uninstall/install operation, so there really is no
such thing as an update (that's what any other package manager I know of
does as well).  I haven't been following the MTA discussions closely,
but the packages must never be dropping their configuration directly
into /etc for instance.  Instead they need to put them into /etc/default
or some other package specific place and then copy those files unless
they already exist.  Package collisions, if done via alternatives, would
notice the appearance or removal of files provided from multiple
packages in postinstall and then rebuild the appropriate link group.

>> 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.

I looked at the project list from the Navigation bar, not the one in the
drop-down.  Doh…  Request has been submitted.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:

More information about the Cygwin-apps mailing list