Mail Archives: cygwin-apps/2002/02/18/23:31:08
===
----- 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 -