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


green fox writes:
> Achim, reguardless of if this code getting into cygwin (or not), could
> you be able to provide a copy of this on public git/whatever server?

I plan to publish my infrastructure, but haven't yet since it a) isn't
feature complete and b) I need to clean up a few things.  I don't want
to fork setup.exe if I can help it.

> I really like this.

Thanks.

> Just for note, in the past, unattended instalation/update using
> automated package management, we resorted into using apt-cyg written
> by Stephen Jungels.

I've looked at apt-cyg and all the other alternative installers I could
find, but they could either not bootstrap Cygwin or would require too
much infrastructure for installation.  That's why I decided to stick
with setup.exe (also because it is the supported Cygwin installer).

Let me briefly describe how it works: I currently use lftp to mirror
Cygwin and Cygport locally (in a pinch you could use setup.exe itself to
do this).  I have locally built packages and (sometimes) the Cygwin
snapshots re-packaged into Cygwin packages as additional package
sources.  I then use a Perl script to combine all package sources, pull
in dependencies of the selected packages and write this out to a new
setup.ini and install hierarchy (optionally with removing unreferenced
files from earlier versions).  I'm injecting additional groups into the
new setup.ini so that I can do different installs from the same
setup.ini easily (I currently have CLI, GUI, Devel, CygDev - but you can
define whatever you want).  This is what then gets distributed to the
software servers and installed via batch files, or you could even put it
on a flash drive or burn a DVD.

This is working and it doesn't require any changes to setup.exe.  The
users can use setup.exe to alter their installations if they think they
know what they're doing and I can keep providing updated versions
without messing up all those installations each time.

As I said, I have additional requirements to provide different releases,
which for the sake of discussion can be simplified to being able to take
a setup.ini and "freeze" it along with all the package files it
references and then be able to install it again in exactly that state at
a later time.

> Its just that we have duplication on effort here, not just me, Achim,
> the cyg-apt(diffrent guy), more then few "Alternative" installers on
> the net, each admin having their own way of ghosting/cloneing/setting
> up cygwin...

I guess anyone trying to get Cygwin into a corporate network is in the
same boat.

> It may not be the intended use-case of the cygwin dev, however with
> all respect, there is a need for a solid cui with /short and sweet
> options/automated install/update/package management/use of
> proxy(s)/cache/use of mirror/alternative dir as source/dl from
> multiple servers/offline/version check/hash check, as a bare minimum
> requirement when managing multilpe clients.

So far, the only things I would want to change in setup.exe is to name
alternative setup.ini files (for which I sent the patch), but given the
resistance I've met I'll check again if I can work around this without
duplicating whole directory trees or using links/junctions.  If it's
possible to do the moral equivalent by just changing the directory
structure, then I'll happily drop the patch.

The remaining wishes are to add an option to again provide the
"install+update" functionality that was briefly present but then got
changed into either "install" or "update" (which currently requires to
start setup.exe two times in a row) and the ability to delete packages
from the command line.  The functionality to do this already is in
setup.exe, there are just no controls for this on the command line.
Maybe an option to suppress the GUI completely would be nice, but I
personally like to have the progress status on screen.

> And setup.exe has very good GUI, with new and improved commandlines,
> its just that it is not suitable for day to day administration
> purpose. However we all have diffrent ways of providing the package
> data. Nfs/mirror/rsync/ftp/p2p/samba/dvd/ghost/proxy, etc,etc...
> Trying to provide "Everything" in setup.exe is cauing the code to get
> into spagetti.

As I said, this is all dealt with outside setup.exe already and I agree
that this should _not_ be bolted onto setup.exe at all.

> My 2cents worth of thought tells me, providing setup.exe as front
> end/stub/gui to call a solid back end package manager is a reasonable
> way to go.

That would be a different setup.exe than we have today.  If Cygwin wants
to go that route, a more capable package backend would be nice, libzypp
anyone?

> For admin purpose using the backend directly. With well
> difined porotocol on package version control, we could start writeing
> / or even re-use existing package managers. Just a thought.

While I'd love to see something like this, see above why the current
state isn't that far from what is needed, at least in the short term.


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]