Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <088001c17227$fe380620$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Roth, Kevin P." <KPRoth AT MarathonOil DOT com>, <cygwin-apps AT cygwin DOT com>
References: <6EB31774D39507408D04392F40A10B2BC1FE13 AT FDYEXC202 DOT mgroupnet DOT com>
Subject: Re: -src package standard: proposal #5 and #5a
Date: Wed, 21 Nov 2001 12:01:02 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 21 Nov 2001 01:00:59.0010 (UTC) FILETIME=[FB655E20:01C17227]

1 - the new behaviour is by design. Otherwise we have the "I have to
manually turn off all xyz pacakges _every time_ I run setup.exe. As for
not showing the previous version, what happens if you want to run
previous curl, current automake and experimental libtool? How should the
GUI allow that? (It does currently, but AFAICT your proposal would make
that difficult.

2 - Added to the wishlist.

3 - metapackages - if you choose a metapackage within the current
chooser, it's dependencies are automatically selected. You can then
deselect them if you wish.

Rob
===
----- Original Message -----
From: "Roth, Kevin P." <KPRoth AT MarathonOil DOT com>
To: <cygwin-apps AT cygwin DOT com>
Sent: Wednesday, November 21, 2001 2:31 AM
Subject: RE: -src package standard: proposal #5 and #5a


And, there are a couple of UI issues that need some help. If new
packages are defaulted to 'install', then #1 will already be solved.
However I think now that you've gone down the road of having all
packages default to 'skip' (excepting category=Base of course) you
should consider keeping it that way. My preference would be for newly
added/updated packages to be VISIBLE (without having to expand the
categories); but not default to install.

Here are the bugs I've noticed:

1: non-installed packages (aka newly added ones) used to default to
"install current".
   The next choice in the revolving action list was "skip", followed by
(I think)
   "install previous".
   But now, they default to "skip", followed by "install previous", ...
   This action needs to change so that Skip is follow by "install
current".
   My preference here would actually be to keep "install previous" out
of this
   list, and only allow installing previous if you click the "Prev"
radio button
   at the top.

2: Category listings -- if I select a package (say curl) from one
category, that
   requires another pkg (say OpenSSL) from a DIFFERENT category, AND if
the 2nd
   category was not yet expanded:  the 2nd package (openssl) appears all
by itself
   underneath its category, and when I click the 2nd category's name to
show the
   rest of the packages in it, it actually closes; I have to click a 2nd
time to
   show all.  My opinion - that first click on the 2nd category should
open the
   full list under that category, rather than hiding the openssl
package.


Also, if you add "meta-packages"; what happens if I choose to install
"workstation",
but then I change my mind and want to switch to something else that
doesn't include
all the same packages; will the required dependancies deselect
themselves also?

--Kevin