ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2002/02/18/23:31:08

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
Message-ID: <009d01c1b8fe$40d7c110$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <bkeener AT thesoftwaresource DOT com>, <cygwin-apps AT sources DOT redhat DOT com>
References: <015a01c1b886$622561b0$0200a8c0 AT lifelesswks> <VA DOT 00000a82 DOT 00e1d48b AT thesoftwaresource DOT com> <002501c1b8e4$9754b5d0$0200a8c0 AT lifelesswks> <VA DOT 00000a85 DOT 002acfa0 AT thesoftwaresource DOT com>
Subject: Re: Setup
Date: Tue, 19 Feb 2002 15:31:07 +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: 19 Feb 2002 04:30:21.0489 (UTC) FILETIME=[24650A10:01C1B8FE]

===
----- Original Message -----
From: "Brian Keener" <bkeener AT thesoftwaresource DOT com>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>;
<cygwin-apps AT sources DOT redhat DOT com>
Sent: Tuesday, February 19, 2002 3:18 PM
Subject: Re: Setup


> Robert Collins wrote:
> > I have emailed trying to start a discussion on this at least twice.
My
> > contention is that this is a factor for setup.ini to take care of,
not
> > setup.exe. It's easier to add entries than have complex logic for
> > removing them when they aren't appropriate.
> >
> So what you're saying is just looking at Current vs Previous - if
there was no
> setup.ini entry for current and there was only an entry for previous
then with
> the default display set to current the selected default action for the
> theoretical package would be uninstall (just as I saw on the Test) -
correct?

No. There is a pretty big difference (IMO) between prev, current and
test.
Prev - distribution with old versions kept around for convenience sake.
Current - distribution with the latest stable versions.
Test - distribution with versions where things break, major changes
occur etc.

Any version of a package can be selected without the use of the
prev/curr/test buttons - they are designed to make wholesale changes to
the environment.

Prev-Current should be minor - to allow backing out of a minor revision
change that introduced a new bug.

Current-Test *may* be very major.

we have currently in the 'default' picking logic:
packageversion * trustp (trusts const t) const
{
  return t == TRUST_PREV ? (prev ? prev : (curr ? curr : installed))
       : t == TRUST_CURR ? (curr ? curr : installed)
       : exp;
}

IOW, for prev, choose an explicit prev, then a current, and then an
installed.
for current, choose a current, and then an installed.
for test (exp), choose the explicit experimental version.

> And in addition if as a maintainer I didn't want this to happen then I
should
> make sure I have a prev,curr and test in setup.ini even if they all
are the
> same file name.

That is one way, it is very manual however. What I'm suggesting is that
*in the absence* of prev:,curr:,test: tags in setup.hint, that upset
always generate a
[test] entry - just like it automatically generates a [prev] entry when
there are two versions in the directory.

> This bears the question (if my previous assumption is correct) what if
my
> setup.ini has a prev, curr, and test file defined but I am doing an
"Install
> from Local Directory" and the test version does not exist on my
system.  I
> would assume that since I defined a test and even though is does not
exist that > my default action would be keep - true?

I'm not sure :}. I'm not sure that that would be appropriate behaivour
in the general case. We really need versioned conflicts: and depends:
lines to make this all work correctly.

Rob

- Raw text -


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