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


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


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