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
Date: Fri, 2 Nov 2001 19:57:41 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: /setup.html please read - feedback desired
Message-ID: <20011102195741.A31898@redhat.com>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <1004700277 DOT 7488 DOT 2 DOT camel AT lifelesswks> <3BE2E3D3 DOT 1050201 AT ece DOT gatech DOT edu> <20011102134846 DOT H26975 AT redhat DOT com> <1004745374 DOT 9086 DOT 77 DOT camel AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1004745374.9086.77.camel@lifelesswks>
User-Agent: Mutt/1.3.21i

On Sat, Nov 03, 2001 at 10:58:58AM +1100, Robert Collins wrote:
>On Sat, 2001-11-03 at 05:48, Christopher Faylor wrote:
>> On Fri, Nov 02, 2001 at 01:20:03PM -0500, Charles Wilson wrote:
>> >Robert Collins wrote:
>> >
>> >
>> >In the "Package file naming" section:
>> >"In the event that a package doesn't sort correctly (for example, from 
>> >...-9-... to ...-10-..., use the setup.hint current, prev and exp labels to 
>> >override the inbuilt sort during the transition period."
>> >
>> >I think setup.hint's are more-or-less required, now.  Otherwise, there's no 
>> >way to set the sdesc, ldesc, dependencies, etc.  So, the "auto-sort" is a 
>> >soon-to-be-vestigial feature; emphasis should be on setup.hint.
>> 
>> I don't think there is any reason to force the versioning in setup.hint.
>> That's sort of error-prone, actually.  Experience has shown that.
>
>OTOH it's the only way we can have
>"really stable"
>"should be stable" and
>"use at own risk"
>
>all available via setup.exe and clearly identified. Without setup.hint,
>a single file is *assumed* to be current. IMO, that's dangerous as we
>get more packages.

Experience has also shown that people rarely have their packages
organized this way, however.  Instead what we've found is that people
modify setup.hint, time passes, and then a new package is uploaded.  The
new package doesn't show up automatically because setup.hint doesn't
reference it and there is a period of confusion as we work things out.

I don't think anyone is apt to think "This is an experimental package.
I'll just put it up on sourceware.  I'm sure the setup updater will do
the right thing."

The way that packages have been updated has been -- "copy the file that
is supposed to be the current one to sources.redhat.com".  If the version
numbering is correct, everything just works.  That's why we have computers --
they're really good at doing stuff like this.  They can figure out versions
automatically without forcing someone, like me, for instance, to have to
remember to update setup.hint.

We could update setup.hint automatically but that's exactly what we're
doing now.  We could insist that everyone fill out all of the version
info in setup.hint and send dunning email when the versions don't jive
but that just adds complication to something that is already working ok.

When the version numbering is strange, or when you need to specify a
test version then, of course, you need a setup.hint.  Otherwise, you
don't.

cgf