[RFC] incremental rebase
Sat Nov 29 19:16:00 GMT 2014
Ken Brown writes:
> Were the new setup programs built from what's currently at your Git
> repo? If so, I have a couple of very minor comments:
Except for the addition of .cmd as an alias for .bat, yes.
>> - // Look for any scripts in /etc/postinstall which haven't been renamed .done
>> - std::string postinst = cygpath ("/etc/postinstall");
>> + // Look for runnable non-perpetual scripts in /etc/postinstall
>> + // this shouldn't happen (leftovers from the previous install?)
> This comment is slightly misleading. It would be clearer to say
> something like, "This happens when a script from a previous install
> failed to run successfully."
Thanks, that's more clear.
>> +Script::Script (const std::string& fileName)
>> + if ( 2 == scriptBaseName.find('_') &&
>> + 0 == scriptBaseName.substr(1,1).find_first_of(allowedTypes) &&
>> + "_" != scriptBaseName.substr(0,1)
> This last test is redundant, since we already know that 2 ==
No it isn't, this last test kicks out scripts that attempt to be run at
the default stratum by making their first character an underscore, like
_p_whatever.sh -- these aren't supposed to exist. The first test checks
the third character, although looking at it I think I should also
implement it with substr.
> AFAICT, this is ready to go, except that you haven't yet implemented
> the sorting of the perpetual postinstall scripts in any given stratum.
Yes, that's still TODO. Given that it's C++ and we already have it in a
sortable data structure I don't expect much trouble.
> And, of course, you will then have to rename 0p_incautorebase.dash to
> make sure it comes first in the perpetual postinstall scripts in
> stratum 0.
That will have to be done for the ITP, yes. Plus the run order of such
scripts must be reviewed and coordinated among any such packages that
use them. I think it would be good if they got extracted from any
uploaded packages and put into a file in the order they'd be run.
> Thanks for showing me your old TeX Live postinstall package.
> It doesn't differ too much from what I posted in
> https://cygwin.com/ml/cygwin-apps/2014-11/msg00141.html, though I
> could probably use your ideas to shave off a few more seconds.
I'm still using it for new installations. Most of the systems I install
on these days thankfully have an SSD, so it is not the big problem it
used to be anymore, but on spinning rust that used to provide a tenfold
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
More information about the Cygwin-apps