Mail Archives: cygwin-apps/2001/11/02/20:22:09
On Sat, 2001-11-03 at 11:57, Christopher Faylor wrote:
> On Sat, Nov 03, 2001 at 10:58:58AM +1100, Robert Collins wrote:
> >
> >OTOH it's the only way we can have
> >"really stable"
> >"should be stable" and
> >"use at own risk"
> >
> >all available via setup.exe and clearly identified. Without setup.hint,
> >a single file is *assumed* to be current. IMO, that's dangerous as we
> >get more packages.
>
> Experience has also shown that people rarely have their packages
> organized this way, however. Instead what we've found is that people
> modify setup.hint, time passes, and then a new package is uploaded. The
> new package doesn't show up automatically because setup.hint doesn't
> reference it and there is a period of confusion as we work things out.
Yes, the root cause of which is that setup.hint is not bound to the
individual files. That's very high on my priority list. It will also
automagically simplifly local installs. The metadata about
prev-curr-test is something that should stay outside the individual
files though, IMO.
> I don't think anyone is apt to think "This is an experimental package.
> I'll just put it up on sourceware. I'm sure the setup updater will do
> the right thing."
It would be nice if it did though, wouldn't it?
> 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.
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?
> We could insist that everyone fill out all of the version
> info in setup.hint and send dunning email when the versions don't jive
> but that just adds complication to something that is already working ok.
Agreed.
> 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 ?
Of course, the parser doesn't grok that yet, but lets assume that it
does. After all we are planning here...
Rob
- Raw text -