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: <10de01c195d2$f332fb80$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>,
   <cygwin-apps AT cygwin DOT com>
References: <NCBBIHCHBLCMLBLOBONKIEFCCIAA DOT g DOT r DOT vansickle AT worldnet DOT att DOT net>
Subject: Re: Gary's Setup.exe v2.162
Date: Sat, 5 Jan 2002 21:22:57 +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: 05 Jan 2002 10:25:01.0090 (UTC) FILETIME=[3B6FB820:01C195D3]

----- Original Message -----
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
> >  After a few more games, selected "Experimental".  Now Doc
> > category "wants" to keep xml2 & xslt but *uninstall* man &
newlib-man.
>
> Yep, this I see.  I read Rob's explanation and FWICT this isn't the
intended
> behavior overall, but there's some question as to where it should be
dealt with.

Yes. I've discussed this in more detail a while back.

> Yeah, I agree, and again I believe the above comment applies.  Rob,
speaking
> from a position of relative ignorance on this particular issue, I
don't think we
> should rely on this being handled solely in setup.ini if it's possible
to do so
> in setup.exe itself, at least as a second line of defense.  Invariably
something
> will get into setup.ini not-quite-right, and setup will start
uninstalling
> people's mans, etc.

The issue is one of knowledge, and of just how the prev/curr/test split
*ought* to behave. IMO the debian (groan) model of three independent
distributions is a good basis to work off. One absolutely stable, one
with the packages that aren't bleeding edge but are not much older, and
one bleeding edge.

However I don't like the difficulties in picking and choosing between
the debian distributions, so copying that model doesn't appeal (every
say *whew*).

On the other hand, I don't like the fact that we maintainers have to
think very carefully before introducing a new package/variant because we
can trash everybody all at once - and there is no window for testing new
packages. From that angle I LOVE the concept of being able to run in
'test' as the default for setup.exe, and have everything test installed.

However: Supplying that capability means we must not promote packages
with no test: version to test, because if we do that, packages can not
be removed from test and left in prev or curr. Why would we want to do
that? Well take tetex-beta for instance. When the new tetex comes
around, it may well need some testing, so it should be test only, but
tetex-beta should no longer be available as test.

The point where the information is available to determine this is
setup.hint....

As for getting the wrong thing into setup.ini, with upset I don't think
that this is an issue. Even if this did happen, it's easier to publish a
new setup.ini than a new setup.exe - one is always updated :}.

Rob