Message-ID: <49945E5C.5090406@etr-usa.com>
Date: Thu, 12 Feb 2009 10:37:32 -0700
From: Warren Young <warren AT etr-usa DOT com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Cygwin-L <cygwin AT cygwin DOT com>
Subject: Re: CygWine 1.0 Beta -- an new cygwin package manager
References: <d508790c0902120825o10428e3bj40b582cebbbf277e AT mail DOT gmail DOT com>
In-Reply-To: <d508790c0902120825o10428e3bj40b582cebbbf277e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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/