ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/11/30/07:13:39

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
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:
the previous stable version,
the current stable version,
the test version

of given packages, or
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


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

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019