Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Date: Mon, 18 Feb 2002 23:46:01 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: Setup
Message-ID: <20020219044601.GA597@redhat.com>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <015a01c1b886$622561b0$0200a8c0 AT lifelesswks> <VA DOT 00000a82 DOT 00e1d48b AT thesoftwaresource DOT com> <002501c1b8e4$9754b5d0$0200a8c0 AT lifelesswks> <20020219040513 DOT GA372 AT redhat DOT com> <009701c1b8fc$a8eedba0$0200a8c0 AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <009701c1b8fc$a8eedba0$0200a8c0@lifelesswks>
User-Agent: Mutt/1.3.23.1i

On Tue, Feb 19, 2002 at 03:19:43PM +1100, Robert Collins wrote:
>
>===
>----- Original Message -----
>From: "Christopher Faylor" <cgf AT redhat DOT com>
>To: <cygwin-apps AT cygwin DOT com>
>Sent: Tuesday, February 19, 2002 3:05 PM
>Subject: Re: Setup
>
>
>> On Tue, Feb 19, 2002 at 12:27:26PM +1100, Robert Collins wrote:
>>If the question is "Should 'upset' add a dummy Test entry for every
>>case where there is no such thing?" then the answer, IMO, is no.  I
>>think the same applies for the case where an initial release of a
>>product is marked test.  Setting up a dummy "Current" which is the same
>>as "Test" would defeat the purpose of "Test".
>
>For the first case, I think the answer is yes, for the second, it
>*should* be no (because, as you say, it would defeat the purpose of
>test).
>
>Otherwise we need a *new* mechanism to tell setup.exe when a package is
>replaced from current to test - that is that no test version exists, and
>that when moving to test, the current version should be removed.

Ok.  We need a new mechanism.  We also need a mechanism that says
"remove this package" and I don't think that the mechanism is to just
move the package to "prev".  Maybe the mechanism is as simple as just
having a setup.hint like:

  setup.hint:
  curr uninstall "This package is now obsolete"

(wouldn't it be cool to have a "bubble" appear with the above words when
you moved the mouse cursor over the package name?)

Actually, in this case, where the package maintainer means to obviously
uninstall something, I think it is acceptable for setup.exe to do so.

>>I think that the bottom line is that setup.exe should NEVER default to
>>Uninstall.  Uninstall should only be on when the user specifically
>>selects it.  Anything else is, IMO, surprising and dangerous.
>
>I agree that the user should be warned before automated uninstalls
>happen.  Thats not ever been the case though in the gui.

I've always considered it a bug when the word "Uninstall" shows up
in the GUI and I didn't specifically click on it.

>Setup doesn't *default* to uninstall.  Two things have to happen: The
>user has to select Test (which means 'give me a testing distribution').
>Their has to be no valid testing version for that package.

If I click on Test, then a whole bunch of Installs show up on the
screen.  If you don't like the word "default" then I'll use
"automatically switch".

I don't think that setup.exe should automatically switch to Uninstall
in any circumstances unless the package maintainer has specifically
indicated that is the correct behavior.  Somehow.

When I click on test I assume it means "Give me all of the test versions".
I think it is acceptable that if there are no test versions, then every
other package shows up as "Skip".  I don't think that we should assume
that the correct behavior is Uninstall.

Actually, this is one of the things that I hate about the current way
setup works.  I don't like the Prev/Curr/Test stuff that much.  It feels
like we're overloading functionality incorrectly but I don't have a real
idea about how to fix it.

cgf