[RFC] incremental rebase
Thu Nov 20 09:23:00 GMT 2014
On Nov 19 13:19, Yaakov Selkowitz wrote:
> 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
> 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?
Wouldn't that be basically equivalent to Achim's strata idea, just
more enforcingly so?
> 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,
It's already called 000-cygwin-post-install.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;
base-cygwin has the advantage that we have a separate package,
should the need for a fix arise.
Most of the 000-cygwin-post-install.sh script could be moved to
setup.exe, though. Creating all the essential distro directories is
now split between setup and base-cygwin, with setup doing the major
If we tweak setup to create /dev, /dev/shm, /dev/mqueue, /etc/fstab.d,
the base-cygwin script could be reduced to
- creating default /etc/fstab
- creating default /etc/nsswitch.conf
- creating the /etc/mtab -> /proc/mounts symlink.
Nothing of this is really essential for the installation, so in
theory, base-cygwin doesn't really need to run before everything else
> * 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;
That's a good idea, IMHO.
> * 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.
I'm not so keen on a mass rebuild. We still also have a good amount of
non-cygport packages. I would appreciate if we could go forward not
demanding a mass rebuild, and if the method allows to co-exist with
"old" packages not yet using this method. A clean cut is nice and all,
but typically it doesn't work as expected, more so if people are
Some middle way between your and Achim's idea, maybe?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin-apps