Christopher Faylor writes: > You'd really be much better served to submit one patch at a time.
Noted. > If you look at bootstrap.sh, you will see why I'm puzzled why this should be > needed. The script is intended to be run from the build directory which > should be separate from the source directory. In all the combinations I tried, this didn't result in a working build environment, but let me try again. It is possible I got fooled by CVSgrab and there's still something missing in my source tree. > "strip" as a target is really not a good idea. I'm not wedded to the name and I really only intend to use "upx" myself (whose name is also up for grabs if you don't like it). > Who is the target audience for this? I'm in the process of updating our age-old "IT approved" Cygwin installation to 1.7.x. One of the things I need to provide is the ability to "freeze" and "roll back" installations to some known state and do it from a script. I have a (not quite finished yet) script infrastructure that collects the necessary files into an install hierarchy and re-writes setup.ini to match that. The current plan is to rename setup.ini to some unique name upon freeze/release and make sure that the files referenced by all these ini files are kept along with any updates that come with a new setup.ini. That way I hope to fulfill that requirement without unduly needing to duplicate gigabytes of data for each release. All this of course only works if "setup.ini" isn't hard-coded into setup. > It doesn't seem like it is worth complicating setup for this type of > feature. If you are talking about the interactive installation method I tend to agree. This change however is intended to add some support for non-interactive installations (and I will likely request some more support for that later on, like deleting packages from the command line). The alternative would be to put each setup.ini in its own directory and link the install hierachy (that works, I've tested it), but the master copy I'm producing will be replicated to some 45 distribution servers around the world in a two- or sometimes three-stage process and I'm trying to avoid testing the chances of the links surviving the replication (over which I have no control other than saying "do it now" and I can't check most of those servers easily). But you are free of course to not wanting to support that and drop the patch, in which case I'll carry it forward locally. No big deal. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
