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