This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [RFC] incremental rebase
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 21 Nov 2014 22:00:18 +0100
- Subject: Re: [RFC] incremental rebase
- Authentication-results: sourceware.org; auth=none
- References: <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> <546E312E dot 8090904 at cygwin dot com> <87h9xtd7k0 dot fsf at Gertrud dot fritz dot box> <20141121203703 dot GI3810 at calimero dot vinschen dot de>
Corinna Vinschen writes:
> Assuming we only have a single rebaseall script along the lines of
> autorebase.bat.
>
> A simple mechanism which works with both of your proposals, without
> much intelligence required, without clobbering, and with easy cygport
> support, would be this:
>
> autorebase.bat gets renamed to 2r-autorebase.bat (Achim) or
> 02-autorebase.bat (Yaakov),
>
> To handle the dependency issue, every package coming with DLLs will not
> create the same 01-rebaseall.{sh,bat} script as Yaakov proposed, but
> rather a script called, for instance,
>
> 1r-needrebase-${packagename}.sh (Achim)
> or 01-needrebase-${packagename}.sh (Yaakov)
For rebase in particular there's no two-step sequencing needed,
actually. Just dropping files with a list of to-be rebased objects is
enough, plus a perpetual script that picks them up before the rest of
the postinstall and feeds them to rebase. But we already have that in
the form of the package.lst.gz files and filtering out the file names to
be rebased from that actually doesn't take much more time then using a
packaged list. Autodep generation would be even easier since setup
knows which file it dropped or deleted and could trigger a rebase based
on that information all by itself. That rule could even be hardcoded,
it's not going to change often.
> Same thing for update-info-dir. Am I missing something?
You're not. That's how triggers are supposed to work for this sort of
thing, especially and can even be auto-generated by setup (package
installs a file in an infodir: run update-info, both on install and
remove) and would not require dropping of trigger scripts.
The objective that shapes my proposal was to not require much support
from either setup or cygport or even manual intervention in the
beginning. Once it is fully implemented, things could be realized very
differently (and hopefully more efficiently) that they are now. They
don't have to, though.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada