[RFC] incremental rebase

Achim Gratz Stromeko@nexgo.de
Thu Nov 20 17:51:00 GMT 2014

Yaakov Selkowitz writes:
> I think we need to back up a step and rethink how we handle
> postinst/prerm in general:
> * it is clear that upset's autodep code isn't working;

It has a very peculiar purpose anyway, and I'm not sure I know what it
really is.  So it might be working, just not as we expect it to.

> * circular dependencies which can mess up the deptree can't always be
> avoided;

Zypper has solved that largely.  But setup has no distinction between
hard and soft dependencies.

> * there can be a lot of duplication in commands when many packages are
> installed/upgraded at once;
> * some packages have multiple postinstall commands, some of which
> really need to be run at different stages.
> So maybe we should move away from using the deptree to determine
> postinstall order, and use numerical sorting instead?  I'm thinking
> along the lines of the fontconfig configuration system here, FWIW.  My
> thought is that every (sub)package could have multiple postinstall
> scripts -- generally autogenerated by cygport -- which would be
> numbered and named in a set system so that everything is run in the
> necessary order.

I'm opposed to a complete manual assignment of this order on principle.
First, it isn't needed for the majority of things and second, it has the
very real potential of requiring huge package rebuild orgies.  Unless
we've got all packages produced from cygport and a build system that
ensures a consistent state of the distribution this is not going to fly.

> For instance:
> * base-cygwin's postinstall would be 00-cygwin-filesystem.sh, in which
> case it could even be part of cygwin itself, since the only need for a
> separate base-cygwin is to be first in deptree;

Put it on an appropriate stratum.

> * EVERY (sub)package with a DLL would include a (cygport-generated)
> 01-rebaseall.bat -- note that this name is NOT package dependent, but
> clobbering is okay wrt postinstall scripts -- which would then cause
> rebaseall to be run only once per install and only when necessary;

No clobbering please, the file to package relationship should remain
bijective.  It's almost impossible to ensure that each such package has
the same version of that script.  Many-to-one relations is what triggers
are for in my proposal.

> * EVERY (sub)package with info files would include a
> (cygport-generated) NN-$PACKAGE-info.sh, which would run install-info
> on its info file(s), *AND* a matching preremove script which does
> install-info --delete to the same (something we've been missing until
> now);

Agreed, except the NN_ part.

> * TeX Live postinstalls could then be broken up into
> appropriately-numbered (cygport-generated) NN-mktexlsr-first.sh,
> NN-updmap-sys.sh, NN-mktexlsr-last.sh, and then some package-specific
> scripts in between those as needed;

That's not how TeXlive works or maybe I don't understand what you're
after here.  In a nutshell, you'd want to collect all installs into a
single invocation of mktexlr and updmap.

> * EVERY (sub)package including fonts would have a (cygport-generated)
> NN-fontconfig-$DIR.sh, so that those commands are run only once per
> directory;
> and so on.
> The idea here is that certain number ranges would be reserved for
> specific early and late commands, and general commands would be given
> a range which they could use.  This would take some advance planning,
> followed by a mass rebuild -- which we need to do sometime anyway for
> a number of other reasons -- but I think the results would be worth
> it.

I think you will find it's an endless task to assign those numbers and
when the first packages arrive with one set you'll already have chosen
differently again.

+<[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