[RFC] incremental rebase

Yaakov Selkowitz yselkowitz@cygwin.com
Wed Nov 19 19:19:00 GMT 2014

Sorry for the delay; I meant to respond last night, but then we ended up 
with an internet outage. :-(

On 2014-11-18 04:49, Corinna Vinschen wrote:
> I'm glad for this initiative, but personally I don't have a strong
> opinion what's the best way to go forward.  I'd just like to see some
> mechanism to allow what Achim's _autorebase replacement does,
> preferredly for _update-info-dir and other packages as well, and Ken's
> request makes sense to me.  And I'd prefer a simple method, which can be
> easily deployed by us maintainers, with the help of cygport if possible.
> Yaakov, as cygport maintainer and distro overlord you are best-suited
> to handle this issue.  Can you please chime in here and move this
> forward?

Is that my new official title? :-D

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;

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

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

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;

* 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;

* 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);

* 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;

* EVERY (sub)package including fonts would have a (cygport-generated) 
NN-fontconfig-$DIR.sh, so that those commands are run only once per 

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.



More information about the Cygwin-apps mailing list