Re: /setup.html please read - feedback desired

[Christopher Faylor <cgf at redhat dot com>]

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