[arch-dev-public] Missing packages?

[Paul Mattal]

Aaron Griffin wrote:
> On Nov 28, 2007 8:40 AM, Paul Mattal <paul at mattal.com> wrote:
>> Travis Willard wrote:
>>> On Nov 28, 2007 8:41 AM, Paul Mattal <paul at mattal.com
>>> <mailto:paul at mattal.com>> wrote:
>>>
>>>     Dan McGee wrote:
>>>      > On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin at gmail.com
>>>     <mailto:aaronmgriffin at gmail.com>> wrote:
>>>      >> The following appear to be missing for i686:
>>>      >>     firefox 2.0.0.10-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
>>> CURRENT.
>>>
>>> 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 
messages altogether.

- P