Mail Archives: cygwin-apps/2001/11/02/20:45:20
On Sat, Nov 03, 2001 at 12:25:29PM +1100, Robert Collins wrote:
>On Sat, 2001-11-03 at 11:57, Christopher Faylor wrote:
>> 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.
>
>Absolutely. My goal is to have it even easier. But there are a
>significant number of steps to get there.
>
>1) we need a package building tool that is data driven al la debian/ or
>.spec.
>2) We need each package file to be standalone, again like deb or rpm.
>3) We need the metadata to be self repairing, or IOW, have a tool that
>lets you do that 'copy' and update setup.hint (for examples sake) in one
>step.
>
>i.e. I'd like to be able to say "cygupload -current package foobar.bz2"
>and have that do the right thing.
If cygupload puts the file on sources.redhat.com, then I'm in favor of
that. If it requires that you include '-current package', then I'm
not sure that I am.
>And if you have a package that is currently experimental, that no one
>has complained about, then
>cygupload -move package test current
>would simply update setup.hint putting the current test version into
>current.
>
>These are rough thoughts, but does the direction seem reasonable?
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.
>>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.
>
>What about when version foo requires less and vim and version bar
>requires less vim cygrunsrv ?
That would qualify as a variant of "version numbering is strange".
What I'm trying to say is that I don't see any reason to require
setup.hint for the, IMO, normal cases.
>Of course, the parser doesn't grok that yet, but lets assume that it
>does. After all we are planning here...
I think that the parser should handle this and I actually think that
much or all of the setup.hint style information should be part of the
package rather than external to it. I think we probably agree on
that.
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.
cgf
- Raw text -