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: <00ce01c17998$37f50940$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-apps AT sources DOT redhat DOT com>
Subject: prev/curr/test behaviour
Date: Fri, 30 Nov 2001 23:08:59 +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: 30 Nov 2001 12:13:23.0529 (UTC) FILETIME=[68522B90:01C17998]

Has anyone tried HEAD since my update (I know, less that 24 hours :} ) ?

Specifically, the prev/curr/test behaviour is _potentially_ wrong.

Here's what I mean.

prev/curr/test can mean 1 of two things:
a:
the previous stable version,
the current stable version,
the test version

of given packages, or
b:
the previous stable version, or the current if no previous,
the current stable version,
the test version or the current if no previous.

Currently the reinstated buttons do a:. Now, if setup.ini always
provided prev and test, setup.exe would *appear* to do b to the users,
but actually do a:. This would be useful in certain circumstances.
i.e. when a package gets replaced by two packages that do what the
single one did, and the old package is removed, with a: it will
correctly uninstall. With b: it *won't*. (This can be address'd by
completely removing the package from the list, but that then breaks
*everyone(*)* who is running on previous for whatever reason - they get
forced to curr for the replacement package, ahead of time.

What I'm saying is that the behaviour in a: seems more sane to me, but
requires more management of setup.ini, whereas b: has less setup.ini
management, but also less capability to have different things in
prev/curr/test - reducing their value somewhat.

So, I'd like some input on this, as changing to b: is easy enough to do,
but I'd like to stay with a:, and doing that will affect upset at a
minimum.

Rob

(*) How many folk do run in the different 'dists'?