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