Mail Archives: cygwin-apps/2001/11/02/21:21:53
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
>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
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
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
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.
- Raw text -