Git/svn/cvs "versions"

Question

Hi,
on the AUR, it looks like when you upload a package that already existed (but another version) the other package gets replaced by the newly uploaded one.  This seems reasonable because usually people upload a newer version and the older one is not needed anymore.
But for git/svn/cvs "versions" this raises a problem: When dealing with 'bleeding edge' packages we usually want to keep the 'stable release' packages as well, but this doesn't work:  when package foo v1 exists and you upload foo-git it will also replace.
I see that most people solve this problem by giving a package a different name instead of another version, eg the package becomes foo-git with version <current date>, which doesn't replace foo version 1.
1) Is there any reason for the <current date> version?  Or is this just because the version variable cannot be empty?  I don't see much semantic meaning in a version like that, because the user will build the package himself anyway (so he will build the _current_ latest version, not the one dated from the version string of the packagename), at least for packages in unsupported.
2) Isn't this more a workaround than a solution?  I mean, isn't having different package names a bit ugly because it's actually the same software, just another version? (eg the git/svn/cvs part should be in the version string, not the package name)
This is a rather theoretical subject (especially question 2), and in true Arch spirit I do think it's better to have a workaround that is simple and works just fine then having the 'theoretically correct' but more complicated solution.
OTOH, assuming agreement with me:  I think it's easy to the implement the 'correct way':   Basically the AUR code should just check if the version of the package matches a knows VCS system ('git','svn',...) and allow it as an additional package, otherwise replace the previous package.  (and if you upload foo-git and foo-git exists already, also replace it of course)

Answer 1

I think there are some misunderstandings in this thread -- maybe on my side.
To be clear: $pkgname, $pkgver and $pkgrel are required fields in a PKGBUILD. Since there is no real version number in packages that are build upon a VCS, often the date is taken as $pkgver (but e.g. svn gives a revision number apart from the date, so that s taken instead). So for example in tuxpaint-cvs-20081116-1, tuxpaint-cvs is the $pkgname, 20081116 is the $pkgver (when you check out CVS packages, the current date of last upstream upload is given as version) and 1 is the $pkgrel (not of much use here). Uploading a tarball for tuxpaint-cvs will not delete an existing tarball for tuxpaint, since tuxpaint-cvs is another name than tuxpaint. If you some day later download the tarball for tuxpaint-cvs, makepkg will generate a package with the current date as $pkgver, unless you say makepkg --holdver, in which case it would take the upload date as $pkgver.
Last edited by Stefan Husmann (2008-11-16 19:17:51)