> -----Original Message-----
> From: Lawrence W. Smith [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 20, 2002 3:19 AM
> Not entirely true sometimes it improves sometimes it meanders
> down a blind alley or two
granted.
> It's free software as a nobody user I accept its oddities and
> enjoy it's strengths, I'd like to contribute some
> constructive feedback but clearly that's not welcome.
Actually it is welcome. Command line based installs are desirable. There
is code in setup.exe to allow contributors to add command line options
quite easily. I'm putting the finishing core touches on a library to
make that simpler still. (getopt based to leverage that, but with OOD).
> > Why doesn't it? Run setup on each workstation.
>
> I don't think that's terribly scalable.
Agreed - thus the push for command line options.
> > If that's too hard, then copy the download directory around to
> > multiple
> > workstations.
>
> Perhaps far more useful would be provide a cmdline mode to
> setup.exe offering a more flexible install method, scaleable
> to multiple installations and capable of saving a specific
> bundle of packages as an install set and then reapplying
> those with a single commandline across a list of boxes.
Sure. How us get there. Others share your vision, I'm sure if you
colelctively put in 3 command line options each, and sent in the
patches, we would get there very quickly.
> neither is it intended to solicit the perennial "go code it
> yourself, we're too busy, response"
It's not about business (sic). It's about the model. I'm the setup.exe
maintainer - that does not mean that I volunteered to code the entire
thing, and there have been some fantastic net contributors who have put
in a lot of effort. They have been addressing the things that interest
them. If no-one actively coding on setup.exe finds what you propose
interesting enough to provide a gift of code, then ... no one will. Thus
you can either attempt to get us interested, or join us as a interested
party.
> As a for instance of the consequences of your approach: How
> would you suggest the mere mortals should clear out old
> versions of packages after say 4 or 5 revisions are sitting
> scattered across directory trees based on 6 different
> mirrors used by a particular user over a 2 year period?
find -mtime 180 | xargs
would be a good start (as a simple approach).
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/