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 21:22:45 -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: <20011102212245.E31918@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> <20011102195741 DOT A31898 AT redhat DOT com> <1004750730 DOT 519 DOT 26 DOT camel AT lifelesswks> <20011102204613 DOT B31918 AT redhat DOT com> <1004752644 DOT 521 DOT 47 DOT camel AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1004752644.521.47.camel@lifelesswks>
User-Agent: Mutt/1.3.21i

On Sat, Nov 03, 2001 at 12:57:23PM +1100, Robert Collins wrote:
>> I think that putting data in setup.hint that can easily be inferred from
>> file names does not make sense.  You can't infer the ldesc, sdesc,
>> category, or requirements from the filename.  You can infer the version
>> number.
>
>You cannot infer the stability. Prev/curr/test actually covers two
>different axes - prev/curr is (or looks like) a version axis, and
>curr/test looks like a stability metric.
>I'm suggesting that the upload tool needs to know how 'stable' a package
>is. And that the three trust levels - prev, curr, test be updated
>orthogonally to each other, with a simple command to indicate that a
>test package is now stable, and likewise for stable->prev. (although as
>stable-prev are on a different axis, having that pair auto migrate would
>make sense to me)

Again, I think we're agreeing.  You can't infer the test status of a
package from its version.  That requires special thought from the
package maintainer and so, of course, they have to do something special
to ensure that setup.ini is updated correctly.

>> However, if I produce a cygwin-1.3.59-1.tar.bz2 with no package info,
>> I still think that 'upset' (the cygwin setup.ini updater) should
>> be able to infer the info.
>
>>From cygwin-1.3.59-1.tar.bz2, I can infer
>package - cygwin
>version - 1.3.59
>suffix  - 1
>I cannot infer 
>category
>sdesc
>ldesc
>requires

Right.  This is almost exactly what I said above.

>And the whole point of the new setup is to stop user questions due to
>missing requirements. category, sdesc and ldsesc are niceties, and not
>mandatory.

Are we disagreeing about something?  I am not sure anymore.

>So I think that a setup.hint containing a requires: line is _mandatory_
>(at a minimum it should list cygwin if the program is linked to cygwin).

I don't have a strong feeling about this.  I don't see why a package
couldn't be inferred to rely on just on cygwin, if there is no other
requirement, though.  Or 'upset' could just do this automatically.  I
guess if we issue a warning and force the behavior, then the package
maintainer would be forced to think about this, though.

I think you are arguing with me (assuming that we're not violently
agreeing) based on the supposition that I'm saying that I don't want
anyone to use setup.hint.  setup.hint needs to hold the package info
that cannot be inferred from the versions.  That's all that I'm saying.

I was just reacting to Chuck's assertion that setup.hint is now the
"normal" method not the "fallback" method for version handling.  I don't
agree with that.

As I've said repeatedly, I expect that setup.hint will eventually hold
all of the information and setup.ini will be generated solely from this.
After that happens, eventually, I expect that there will be a file in
the package itself which contains this info and maybe setup.hint will
disappear.

Right now most of the information is concentrated in setup.ini.  It was
a lot easier for me to manipulate all of the package info in setup.ini
than it would have been to have it in 88 different directories.  I expect
this to change.

I hope that package maintainers will start updating the info in
setup.ini by adding setup.hint files.  I don't think we have to ask them
to add 'prev' and 'curr' options unless version numbering is strange or
there is a 'test' requirement.

cgf