> 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.

Everyone else does assume this, which is a logical problem.

> 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.

What situations cause these two different cases?

My understanding is that a missing package is one that's been tagged as
CURRENT but we have no package file available for it.

> 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.

I think you're confused. Our db scripts don't work like the aur db
scripts. If a package is tagged but not uploaded the db scripts continue
working. It's very rare that the db scripts won't work for future package
updates if a current update can't be found.

Jason
_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public

On Thu, November 29, 2007 02:33, Travis Willard wrote:
> 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
>> > <mailtoaul@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.

For larger packages (kernel), I have on the occasion, hit extrapkg and
then gone to bed. I've got shocking upload rates here. I'd hate to be
uploading OOo. And yeah... these are the exception.


_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public