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: [PATCH] setup.exe


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


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