This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [RFC] incremental rebase
- From: Yaakov Selkowitz <yselkowitz at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 20 Nov 2014 12:21:34 -0600
- Subject: Re: [RFC] incremental rebase
- Authentication-results: sourceware.org; auth=none
- References: <87k32vjm3i dot fsf at Rainer dot invalid> <5468BD6D dot 5020905 at cornell dot edu> <87bno7jewx dot fsf at Rainer dot invalid> <5468D4FC dot 6000400 at cornell dot edu> <87y4rbhuwa dot fsf at Rainer dot invalid> <5469D55C dot 10506 at cornell dot edu> <87d28lodar dot fsf at Rainer dot invalid> <20141118104947 dot GY3151 at calimero dot vinschen dot de> <546CED28 dot 50207 at cygwin dot com> <87y4r5damb dot fsf at Gertrud dot fritz dot box>
On 2014-11-20 11:50, Achim Gratz wrote:
Yaakov Selkowitz writes:
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;
It has a very peculiar purpose anyway, and I'm not sure I know what it
really is. So it might be working, just not as we expect it to.
As things stand now, EVERY package should requires: cygwin, all packages
with DLLs should requires: _autorebase, and all packages with info files
should requires: _update-info-dir. As you can see from setup.ini,
that's clearly not happening, nor have I managed to find any rhyme or
reason for those that do versus those that don't.
* 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.
I'm opposed to a complete manual assignment of this order on principle.
First, it isn't needed for the majority of things
Exactly: a few known tasks -- most of which are already handled by
cygport -- will need to be planned out, and everything else can go in a
range where order doesn't really matter.
and second, it has the very real potential of requiring huge package rebuild
We need _one_ anyway, but how do you foresee this requiring more later?
Unless we've got all packages produced from cygport and a build system that
ensures a consistent state of the distribution this is not going to fly.
TBH, that is the goal.
* 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;
Put it on an appropriate stratum.
Huh?
* 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;
No clobbering please, the file to package relationship should remain
bijective. It's almost impossible to ensure that each such package has
the same version of that script. Many-to-one relations is what triggers
are for in my proposal.
While I generally agree wrt clobbering, postinstall scripts are (the?)
one place where it is not a problem because the scripts are renamed to
.done after being executed. As for the contents of the scripts, they
would all be identical because they would all be generated by cygport.
* 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;
That's not how TeXlive works or maybe I don't understand what you're
after here. In a nutshell, you'd want to collect all installs into a
single invocation of mktexlr and updmap.
IIRC there are other commands which do depend on the contents of the
collection, but Ken could better clarify.
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 think you will find it's an endless task to assign those numbers and
when the first packages arrive with one set you'll already have chosen
differently again.
It will take a bit of advanced planning, but most of this could be
handled by cygport.
Yaakov