[RFC] incremental rebase

[Yaakov Selkowitz]

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