This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] setup.exe
On 1/20/13, Achim Gratz wrote:
> 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.
Agrred. No one likes to fork, and that includes myself.
And believe me, clean up of code will never happen. We've got a
rollout script that noone dare touches it to clean it up. And it
grows, too.
The lack for any good (standard) bootstrap method for mass deployment
is a problem.
And everybody result in writing one'sown in-house version.
> 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
Diffrent vehicle(rsync), but same here.
Diffrence is, we gave up on the setup.ini route in the past, but if
the setup.ini thing works nicely, this is cleaner approach than what
we've got.
Having to build and deploy custom packages, wrote a quick and dirty
script that makes a self extracting archive blob. Then it pushes
out/exec on remote. Very dirty, but we had a existing base for pushing
out binary blobs/remove executon anyway.
> This is working and it doesn't require any changes to setup.exe.
Very cool :-)
> 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.
Actually this is the most important thing lacking from the curernt situation.
We have a mirror that holds packages of (current and past )specific
versions, and
the freeze/save state is performed by the (avobe mentioned) blob maker
(that can re-create the same blob , as long as supplied with same list
).
But this is not the best way to do things. It's jsut a workaroud,
that's been used for years.
> I guess anyone trying to get Cygwin into a corporate network is in the
> same boat.
>
really need a solid package manager for cygwin.
> 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.
+1 on providing a solid option
As a minimum having install|remove|update|show|find|depends would be needed.
And if possible
-mirror <url> : set mirror to download package( can specify multiple)
-cache <dir> : set cache directory to use
(for packages that may aready been downloaded/partial download in progress)
Something like combination of the exsiting [--local-install]
[--local-package-dir]
-file, -f <file> : read package list to install/remove from file
([-P] from a file)
-force : Force install/remove
> Maybe an option to suppress the GUI completely would be nice, but I
> personally like to have the progress status on screen.
>
I believe there is [--quiet-mode]
>> 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?
>
It was just a dream.
But really, having only curr|prev|test for version control is not funny.