This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CygWine 1.0 Beta -- an new cygwin package manager

Hi brother, thanks for all you reviews and suggestions.

I like yum and apt-get too.

CygWine still in somewhat early age, I will consider your proposals
seriously during the next release.



On Fri, Feb 13, 2009 at 1:37 AM, Warren Young <> wrote:
> Brant Young wrote:
>> I have launched a opensource project -- CygWine ( a cygwin package
>> management utility, project homepage: )
> 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:
> Problem reports:
> Documentation:
> FAQ:         

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]