Aaron Griffin wrote:
> On Nov 28, 2007 8:40 AM, Paul Mattal <email@example.com> wrote:
>> Travis Willard wrote:
>>> On Nov 28, 2007 8:41 AM, Paul Mattal <firstname.lastname@example.org
>>> Dan McGee wrote:
>>> > On Nov 28, 2007 2:25 AM, Aaron Griffin <email@example.com
>>> <mailto:firstname.lastname@example.org>> wrote:
>>> >> The following appear to be missing for i686:
>>> >> firefox 18.104.22.168-2
>>> >> pidgin 2.3.0-1
>>> >> ddrescue 1.6-1
>>> Interesting. I haven't actually run the db update script to put
>>> ddrescue 1.6-1 in the repo yet. Why, then, would it report it
>>> missing? It appears 1.5-1 is still in the db file.
>>> It's missing because that's the version of the PKGBUILD in cvs marked
>>> The CURRENT tag is _supposed_ to mean "this is the version currently in
>>> the repo" - if you've tagged a package CURRENT and not added the package
>>> into the db, then you've made a mistake.
>> I disagree. Often you need to build and upload a set of packages
>> (using devtools) and you want to upload them as you build them but
>> drop them in the repo at once because they need to be released together.
>> Furthermore, it seems silly to consider the package missing when the
>> database file and the package file for the old version are still in
>> the repo.
>> If we want the CURRENT flag to really mean what you say, we should
>> have the DB scripts do the tagging.
> Travis is right here. Even if this is not what _you_ assume, it is
> what the database scripts assume, and unless you want to fix them
> (soon, as in today) to not work like that, then it'd be nice if you
> simply moved the CURRENT tag
> $ cvs tag -Fr 1.7 CURRENT system/ddrescue/PKGBUILD
> Furthermore, you are actually always the person who says the DB
> scripts *MUST* check our source control and *MUST* ensure version
> matches. This statement appears to be the reverse of that. Or are you
> saying that the PKGBUILD need not be tagged/marked latest, but just be
> "one of the PKGBUILDs in source control"? How exactly would we ensure
> the constraint you've always wanted without a tagging mechanism as is
> currently in use
Sorry to have apparently started quite a debate here.
My point was not about what the CURRENT flag *should* mean but about
what it does mean. Since it's possible to get the two out of sync
(fairly easily, in fact), I don't assume that CURRENT == exactly
what's in the repo.
That said, I think the best outcome for right now would be to add
some language to the failure indicating WHY the package is
"missing".. because it hasn't yet been put in the db vs. ones that
already have, because the second is a much more important
issue/problem than the first to those trying to use the package.
One day we'll solve the problems fully, and I didn't mean to upset
everyone over all this. I just wanted to point out that the repo
isn't necessarily in an inconsistent state when this particular
scenario occurs, and by throwing the *same* error when the actual
repo is hosed vs. when it is not tends to make people ignore the
arch-dev-public mailing list