[arch-dev-public] Missing packages?

newer
[arch-dev-public] msmtp, ssmtp,...

older
[arch-dev-public] [signoff] psmisc...

Aaron Griffin

28 Nov 2007 28 Nov '07

8:25 a.m.

The following appear to be missing for i686: firefox 2.0.0.10-2 pidgin 2.3.0-1 ddrescue 1.6-1 I *think* these missing packages might actually be causing a DB issue brought up on the pacman-dev list. If you look at the extra db entries, firefox has a filename pointing at the 2.0.0.10-1 version, which is still on the ftp, but the version is listed as 2.0.0.10-2 I don't know if the other two are affected

Show replies by date

Dan McGee

28 Nov 28 Nov

1:15 p.m.

On Nov 28, 2007 2:25 AM, Aaron Griffin wrote:

...

The following appear to be missing for i686: firefox 2.0.0.10-2 pidgin 2.3.0-1 ddrescue 1.6-1

Simo- I know you built pidgin for me, what hapened here? -Dan

Paul Mattal

1:41 p.m.

Dan McGee wrote:

...

On Nov 28, 2007 2:25 AM, Aaron Griffin 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. This seems like erroneous erroring on the part of the db update script; it should not consider packages missing until *that* dev runs the update script, not any dev. - P

Alexander Baldeck

1:52 p.m.

Paul Mattal wrote:

...

Dan McGee wrote:

...
On Nov 28, 2007 2:25 AM, Aaron Griffin 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.

This seems like erroneous erroring on the part of the db update script; it should not consider packages missing until *that* dev runs the update script, not any dev.

- P

Hey all, I did update firefox yesterday and since I always do a local pkgrel bump for /usr I accidently checked that PKGBUILD in. While I was hecticly removing thigs I caused a syntax error in build. Oh well, pidgin seemed to be missing already when I ran db for the first time. Cheers, Alex

Travis Willard

2:08 p.m.

On Nov 28, 2007 8:41 AM, Paul Mattal wrote:

...

Dan McGee wrote:

...
On Nov 28, 2007 2:25 AM, Aaron Griffin 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.

...

This seems like erroneous erroring on the part of the db update script; it should not consider packages missing until *that* dev runs the update script, not any dev.

Paul Mattal

2:40 p.m.

Travis Willard wrote:

...

On Nov 28, 2007 8:41 AM, Paul Mattal mailto:paul@mattal.com> wrote:

Dan McGee wrote: > On Nov 28, 2007 2:25 AM, Aaron Griffin 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. 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. - P

Travis Willard

3:33 p.m.

On Nov 28, 2007 9:40 AM, Paul Mattal wrote:

...

Travis Willard wrote:

...
On Nov 28, 2007 8:41 AM, Paul Mattal mailto:paul@mattal.com> wrote:

Dan McGee wrote: > On Nov 28, 2007 2:25 AM, Aaron Griffin 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"?

James Rayner

29 Nov 29 Nov

10:49 a.m.

On Thu, November 29, 2007 02:33, Travis Willard wrote:

...

On Nov 28, 2007 9:40 AM, Paul Mattal wrote:

...
...
On Nov 28, 2007 8:41 AM, Paul Mattal mailto:paul@mattal.com> wrote:

Dan McGee wrote: > On Nov 28, 2007 2:25 AM, Aaron Griffin 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

Travis Willard wrote: 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.

Aaron Griffin

28 Nov 28 Nov

4:32 p.m.

On Nov 28, 2007 8:40 AM, Paul Mattal wrote:

...

Travis Willard wrote:

...
On Nov 28, 2007 8:41 AM, Paul Mattal mailto:paul@mattal.com> wrote:

Dan McGee wrote: > On Nov 28, 2007 2:25 AM, Aaron Griffin 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.

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

Paul Mattal

5:33 p.m.

Aaron Griffin wrote:

...

On Nov 28, 2007 8:40 AM, Paul Mattal wrote:

...
Travis Willard wrote:

...
On Nov 28, 2007 8:41 AM, Paul Mattal mailto:paul@mattal.com> wrote:

Dan McGee wrote: > On Nov 28, 2007 2:25 AM, Aaron Griffin 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.

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

Aaron Griffin

5:43 p.m.

On Nov 28, 2007 11:33 AM, Paul Mattal wrote:

...

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.

It's not a debate. I'm saying this: Whatever you may believe, here is how the db scripts work. Please either fix them, or simply retag your PKGBUILD with the command I provided. There's no debate. The scripts function this way regardless of how you *think* they work. The CURRENT and CURRENT-64 tags must match whats in the repos, or it yells. This is not a fatal error, but it is still an error - it doesn't break our DB but it breaks everyone's abs checkout by giving them a PKGBUILD that we're not even using.

...

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.

Sure, go ahead, the scripts are in CVS right now. I can update gerolde with the new scripts that have your feature in it - just let me know when it's in

...

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.

As I said, the pacman DBs are not in an inconsistent state, but now ABS is.

Jason Chu

6:26 p.m.

...

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

5986

Age (days ago)

5987

Last active (days ago)

List overview

Download

11 comments

7 participants

participants (7)

Aaron Griffin
Alexander Baldeck
Dan McGee
James Rayner
Jason Chu
Paul Mattal
Travis Willard