Mail Archives: cygwin-apps/2001/11/02/19:56:55
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
- Raw text -