Aaron Griffin wrote:
On Nov 28, 2007 8: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.
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