[RFC] incremental rebase
Corinna Vinschen
corinna-cygwin@cygwin.com
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
> >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?
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.
Idle thought:
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
part anyway.
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
anymore.
> * 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);
Ditto.
> * 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.
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
involved.
Some middle way between your and Achim's idea, maybe?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20141120/21d7af0d/attachment.sig>
More information about the Cygwin-apps
mailing list