[arch-dev-public] Missing packages?

Travis Willard travis at archlinux.org
Wed Nov 28 10:33:07 EST 2007

On Nov 28, 2007 9: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
> >      >>     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.

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

I'm curious - what do you interpret the CURRENT flag to mean, if not "the
version CURRENTly in the repo"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20071128/8de4ddc2/attachment.htm>

More information about the arch-dev-public mailing list