[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
avoided;
* 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
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.
Thoughts?
Yaakov
More information about the Cygwin-apps
mailing list