Mail Archives: cygwin/2009/02/12/12:37:58
Brant Young wrote:
>
> I have launched a opensource project -- CygWine ( a cygwin package
> management utility, project homepage: http://cygwine.googlecode.com )
My initial thought on seeing the name is that it was a port of Wine to
Cygwin, which would be tres silly.
We don't really need two different installers, so I hope you find a way
to merge your efforts with those working on setup.exe. The licenses are
the same. If that happens, then maybe your program just becomes
setup.exe, and the naming issue goes away, too,
On starting it here, I get an error message about being unable to load
from /setup.bz2. I then manually set a mirror, which did nothing until
I restarted the app. Your program shouldn't have to ask for either of
these things: it can get them from the same place setup.exe does. If it
has neither, it should ask, like setup.exe does, before it presents the
package list.
When I clicked (Re)Install Cygwin, its first choice of directory to
upgrade is my Cygwin 1.5 directory, not my 1.7 directory. It's not
clear to me if this means it just looks for 1.5 first, or if it really
only supports 1.5. I don't want to wreck anything, so I haven't used
CygWine to install anything yet.
Speaking of, one of the weaknesses of setup.exe is that it gets confused
if you have Cygwin 1.7 installed in c:\cygwin (as I do) and then try to
install 1.5 somewhere else. It happens because the 1.5 version of
setup.exe grabs the package list from c:\cygwin, not realizing that it's
for a different version of Cygwin. I don't know how much work you want
to put into making your program cope with two versions of Cygwin, but
you should take some care not to entangle them if they're both present.
How exactly you go about that depends on whether you want to support
both versions at all -- maybe you intend to support only 1.7, given that
1.5's run is almost over.
I like that it detects which Cygwin-using programs are running and names
them for you, instead of making you guess which files conflict, as
setup.exe does. I also like that it's proactive, not waiting until it
encounters a file copying error to complain. Your program should also
handle that copying error, but the proactive approach should make that
code path difficult to hit.
The only problem is, you're doing that check too early, before you know
whether the advice in the dialog is actually correct. It asked me
before I'd even selected any packages to download. There's no way it
knows what I need to shut down so early. It should wait until all the
tarballs are down, then look into them to see what files will be
replaced, and figure out whether any files currently loaded into memory
will be replaced. Unless you're replacing a running service, bash, or
cygwin1.dll, changes are good that you can install while those things
stay running.
A long-standing wishlist item for setup.exe is something like you see in
Linux distributions, where the installer abstracts away the full package
list, with its first screen showing a relatively small number of
groups of mutually coherent and supporting sets of packages. You can
still get at the full package list, but the idea is that most people
will just select those package sets that include the functionality they
want. This ends up installing more packages than is strictly required,
but human time is more expensive than bandwidth in most cases.
For instance, I'd like to be able to select the "Text Based Internet"
category and get ssh, rsync, lynx, wget, and lftp. When there are
multiple packages in Cygwin providing a given function (e.g. lynx,
elinks, and w3c), you should just pick one and call it your standard.
I'd also like to see a command line interface to the program, and for
CygWine to install itself into c:\cygwin\bin. I'd like to be able to
say "cygwine install rsync" from a bash prompt, and have it
automatically go to the last mirror I selected through the GUI, grab the
package and its dependencies, place them in the last place it downloaded
packages[*], and install them. If you do this, please copy the command
line format of one of the tools that do this on other OSes. I'd prefer
yum, but apt-get or fink would be fine. These three all have
differences, despite being so similar in effective function. This wheel
has been reinvented enough times now.
Combining these two, the way I'd most like it to work is this:
1. Start CygWine, it asks you where to install, what mirror to use,
etc., like setup.exe does
2. Then it gives you a list of maybe 20 groups of packages. Checking
off all of them doesn't install absolutely everything, just that subset
that provides all of the named functions. You then have a branch:
3a. Click Install to install those package groups
3b. Click Select Individual Packages to switch into the current CygWine
view. The packages belonging to the groups you selected on the previuos
screen are already checked off. Then you can add or remove packages at
this stage, then click Install to proceed.
4. Once installed, you can install more packages or do a "cygwine
upgrade" command from the bash prompt, and not use the GUI any more.
The GUI should still work, it just shouldn't be necessary.
[*] I currently keep setup.exe and all the files it creates during the
download phase on a network drive, so I only have to download a given
package once. I'd expect to be able to keep doing that in a world where
I use the GUI only to get a base system set up, then install packages
individually after that at need.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -