Re: [RFC] incremental rebase
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
Re: [RFC] incremental rebase
On 11/16/2014 11:20 AM, Achim Gratz wrote: Ken Brown writes: Would it be very hard to allow perpetual postinstall scripts to run either before or after all others? Not any harder than what is already there. ALthough if we are going to create even more strata of postinstall phases I'd opt for some refactoring. I could make very good use of this for improving the texlive postinstall process. It's possible to do this with a perpetual script, assuming you use the actual postinstall scripts to create some trigger condition for the perpetual script to act upon, yes. I'm not sure if this is the best or even most easily implemented solution, though. 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. Ken
Re: [RFC] incremental rebase
Ken Brown writes: > Would it be very hard to allow perpetual postinstall scripts to run > either before or after all others? Not any harder than what is already there. ALthough if we are going to create even more strata of postinstall phases I'd opt for some refactoring. > I could make very good use of this for improving the texlive > postinstall process. It's possible to do this with a perpetual script, assuming you use the actual postinstall scripts to create some trigger condition for the perpetual script to act upon, yes. I'm not sure if this is the best or even most easily implemented solution, 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
Re: [RFC] incremental rebase
On 11/16/2014 8:45 AM, Achim Gratz wrote: As discussed on the main list, here's the incremental autorebase package as well as the patched setup.exe to implement perpetual postinstall scripts. $cygwin=http://cygwin.stromeko.net/ wget $cygwin/noarch/release/_incautorebase/_incautorebase-6-1.tar.bz2 wget $cygwin/x86/setup-x86.exe wget $cygwin/x86_64/setup-x86_64.exe As briefly mentioned, the implementation was done to minimize the changes to both the infrastructure and the size of the patch to setup. This could be implemented differently, for instance based on the directory the script is in, rather than its name. Also, in the same way one could look at the name of the script and have certain scripts run before or after the others, or use hidden groups (like _PostInstallLast and have it actually do what that name suggests). Another obvious extension would be triggers, i.e. the installation of one (or multiple) packages will result in the execution of the triggered postinstall script. This is useful if the same postinstall action can be used by many packages (texlive would benefit enormously from that). This would require changes to the packaging, upset, setup or all of them, of course. I suggest to start with this and take it from there. Would it be very hard to allow perpetual postinstall scripts to run either before or after all others? The names could end in _always_before or _always_after to indicate which type of script it is. It seems unnecessarily limiting to assume that all perpetual postinstall scripts should run before all others. I could make very good use of this for improving the texlive postinstall process. Ken
[RFC] incremental rebase
As discussed on the main list, here's the incremental autorebase package
as well as the patched setup.exe to implement perpetual postinstall
scripts.
$cygwin=http://cygwin.stromeko.net/
wget $cygwin/noarch/release/_incautorebase/_incautorebase-6-1.tar.bz2
wget $cygwin/x86/setup-x86.exe
wget $cygwin/x86_64/setup-x86_64.exe
As briefly mentioned, the implementation was done to minimize the
changes to both the infrastructure and the size of the patch to setup.
This could be implemented differently, for instance based on the
directory the script is in, rather than its name. Also, in the same way
one could look at the name of the script and have certain scripts run
before or after the others, or use hidden groups (like _PostInstallLast
and have it actually do what that name suggests).
Another obvious extension would be triggers, i.e. the installation of
one (or multiple) packages will result in the execution of the triggered
postinstall script. This is useful if the same postinstall action can
be used by many packages (texlive would benefit enormously from that).
This would require changes to the packaging, upset, setup or all of
them, of course.
I suggest to start with this and take it from there.
The patch to setup is this:
Subject: [PATCH 1/5] implement perpetual scripts and run them before all other
postinstall scripts
* postinstall.cc (RunFindVisitor): Exclude perpetual scripts (having suffix
"_always" before the extension) from being returned.
* postinstall.cc (PerpetualFindVisitor): New helper class, returns perpetual
scripts (having suffix "_always" before the extension).
* postinstall.cc (do_postinstall_thread): Search for perpetual scripts
and run them before all other postinstall scripts.
* script.h (perpetual): New helper function, returns true if the
script is a perpetual one.
* script.cc (perpetual): If the script name has suffix "_always"
before the extension, then assume it is a perpetual one.
* setup/script.cc (run): Do not append suffix ".done" to perpetual
scripts.
---
postinstall.cc | 56
script.cc | 11 +--
script.h | 1 +
3 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/postinstall.cc b/postinstall.cc
index 6f6502d..cca741a 100644
--- a/postinstall.cc
+++ b/postinstall.cc
@@ -54,8 +54,8 @@ public:
const WIN32_FIND_DATA *theFile)
{
std::string fileName(theFile->cFileName);
- if (fileName.size() >= 5 &&
- fileName.substr(fileName.size() - 5) == ".done")
+ if ( (fileName.size() >= 5 && (fileName.size() - 5) == fileName.find(".done"))
+ || (std::string::npos != fileName.rfind("_always.")))
return;
std::string fn = std::string("/etc/postinstall/") + theFile->cFileName;
_scripts->push_back(Script (fn));
@@ -68,6 +68,28 @@ private:
vector
Re: upset errors: lzo2 package - can't seem to upload anything
> Yaakov Selkowitz writes: > On 2014-11-15 10:16, Dr. Volker Zell wrote: >> Can't we just rename the current liblzo2 directory to lzo2 ? I want the >> packages to be symmetric between x86/x86_64. > They already are: > ftp://ftp.cygwin.com/pub/cygwin/x86/release/liblzo2/ > ftp://ftp.cygwin.com/pub/cygwin/x86_64/release/liblzo2/ But there was a time when you uploaded the first 64bit version of liblzo2 when I was busy, and you used just lzo2 as the main directory and there used to be a lzo2-2.06-1-scr.tar.bz2 file. I still have that directory in my cygwin package download cache. Thats why I wanted to make the latest 32bit version directory structure compatible with the 64bit one. But your above links show that someone actually renamed everything back as I was using it. > OTOH I don't mind renaming the source package; let me know how you wish to > proceed. I will upload soon with the orignal naming scheme. Ciao Volker
SSH key for upload access
Name: Daniel Boland Package: procmail BEGIN SSH2 PUBLIC KEY Comment: "2048-bit RSA, converted by daniel@dimension from OpenSSH" B3NzaC1yc2EDAQABAAABAQDVlIM8TfGSHpmiAwsSEhICBk7CWSTHkH+3hQDO25 jpVcbcsL3+ETIjXENz8Ik3gxZbO9l5AFMZWKx3wjK1ev5SbIQ3u7vRZOjWMLmTBOgMTh19 Bn9uDd/2l0cKTrb4x2lm9GWpkh9CN1at0wgohMFLi6v/x3L17Bn54YToin+sGBkh6djJio 0bt0P7SpdwgOFGSYdQbxAvmPhXi5RMO9VKXkCud2taoOac4IxtaEgiTi8CuoVWwDlQ4uLo JHljGr5vH4Ap7W5MGVN00GnQ/pp7uOR3CRHsel8Hjx5w2/yBIIwAcm5sEpL6CkuKVPLEQQ yl6Wn/xZAvcoYZSjL6+Mkn END SSH2 PUBLIC KEY
Re: postgresql: use system tzcode
On 11/16/2014 9:09 AM, Yaakov Selkowitz wrote: Marco, Currently, postgresql ships with a bundled (and old) version of tzdata. Instead, could you configure postgresql with --with-system-tzdata=/usr/share/zoneinfo and add tzcode to postgresql_REQUIRES? -- Yaakov No problem. I will add to next 9.4 package. Current beta 3 seems still using 2010c Regards Marco
postgresql: use system tzcode
Marco, Currently, postgresql ships with a bundled (and old) version of tzdata. Instead, could you configure postgresql with --with-system-tzdata=/usr/share/zoneinfo and add tzcode to postgresql_REQUIRES? -- Yaakov
Re: upset errors: lzo2 package - can't seem to upload anything
On 2014-11-15 10:16, Dr. Volker Zell wrote: Can't we just rename the current liblzo2 directory to lzo2 ? I want the packages to be symmetric between x86/x86_64. They already are: ftp://ftp.cygwin.com/pub/cygwin/x86/release/liblzo2/ ftp://ftp.cygwin.com/pub/cygwin/x86_64/release/liblzo2/ OTOH I don't mind renaming the source package; let me know how you wish to proceed. -- Yaakov
