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
pgpy_cy4wXowj.pgp
Description: PGP signature