This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] incremental rebase


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

Attachment: pgpVWFkNum7Ch.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]