On Nov 28, 2007 9:40 AM, Paul Mattal <paul@mattal.com> wrote:
Travis Willard wrote:
> On Nov 28, 2007 8:41 AM, Paul Mattal <paul@mattal.com
> <mailto: paul@mattal.com>> wrote:
>
>     Dan McGee wrote:
>      > On Nov 28, 2007 2:25 AM, Aaron Griffin <aaronmgriffin@gmail.com
>     <mailto:aaronmgriffin@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.

I agree that this is a common and useful thing to do, however with rxvt-unicode and firefox I don't think this was the case.

Besides, when you build and upload a set of packages, you do so with the intention of adding them to the repo after they're all uploaded.  There will be a little incongruence between the time the first package is uploaded and the last one is uploaded, but ideally you wouldn't start using 'extrapkg' or the like until you were ready to put them all into the repo at once.

I don't personally see the use case of 'build half tonight, extrapkg them, go to sleep, build the second half tomorrow, extrapkg them, then run /arch/db-extra" as a valid case - if that's the workflow, then extrapkg should be used only when you're ready to put stuff into the repos.
 

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.

The package is considered missing because the CVS tag is telling the db scripts to expect that package.  In light of that meaning, it's not silly - it's basically telling you which packages are marked CURRENT but not in the repo itself.
 

If we want the CURRENT flag to really mean what you say, we should
have the DB scripts do the tagging.

I also agree that the ideal place to tag the repo is upon actual insertion into the DB.  The problem is that, at current, the DB scripts use the CURRENT tag to determine which version is supposed to be in the repo and update the database accordingly.  We'd have to include a distinct method of telling the DB scripts "Hey, this is the version we want" that doesn't rely on CURRENT.

I'm curious - what do you interpret the CURRENT flag to mean, if not "the version CURRENTly in the repo"?