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