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: Sun, 16 Nov 2014 19:17:57 +0100
- 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>
Ken Brown writes:
> It might not be the best solution long term, but I could achieve
> substantial improvement without a great deal of effort. See
>
> http://tug.org/pipermail/tlbuild/2014q4/003072.html
>
> for an indication of what I'd like to do. The author of that message
> isn't aware of the issues involving the order of the postinstall
> scripts, but I could do everything he suggests if I had a perpetual
> "after" postinstall script.
This looks more or less like what I suggested in this thread:
http://thread.gmane.org/gmane.os.cygwin.applications/23867
So, lets pretend we have pre- and post-postinstall perpetual scripts.
Independently of when they are run, they need to decide whether or not
they should do anything. The incremental rebase uses timestamps and
since all files involved are nominally under control of setup.exe that
should be OK (I haven't added something to correct the timestamp on the
package listing files if these have been moved forward in time). With
TeXlive that's not quite as clear cut. Also, there should be a
possibility to trigger a full rebuild of everything to make the state
consistent. The incremental rebase package can be re-installed to get
that effect. I think that should work for TeXlive, too, but that means
there must be one more additional package that you can then tell people
to re-install.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra