git/svn/cvs "versions"

Dieter@be · 2008-11-16 15:55:00

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)

Daenyth · 2008-11-16 16:37:42

I'd say the current system works fine. Compare with for example, python{,25,26}, qt{,4}, and so on.

Ghost1227 · 2008-11-16 16:55:45

I don't see any problem with the way things are...

Stefan Husmann · 2008-11-16 19:05:31

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)

tomk · 2008-11-16 19:08:13

Apart from the AUR's requirements, you need to consider how pacman handles things. There is currently no way for pacman to install two different versions of any package simultaneously, hence the need for a different package name for the package built from git/svn/etc.

Profjim · 2008-11-16 20:24:48

tomk wrote:

Apart from the AUR's requirements, you need to consider how pacman handles things. There is currently no way for pacman to install two different versions of any package simultaneously, hence the need for a different package name for the package built from git/svn/etc.

tomk, I agree that the current system has many virtues, but I'm not sure I follow this particular argument. Isn't the standard practice for a FOO-svn or FOO-git package to declare conflicts=(FOO) and provides=(FOO)? One would normally have to do special work in the PKGBUILD to install the svn/git version alongside, instead of replacing, the base version.

Arch Linux

#1 2008-11-16 15:55:00

git/svn/cvs "versions"

#2 2008-11-16 16:37:42

Re: git/svn/cvs "versions"

#3 2008-11-16 16:55:45

Re: git/svn/cvs "versions"

#4 2008-11-16 19:05:31

Re: git/svn/cvs "versions"

#5 2008-11-16 19:08:13

Re: git/svn/cvs "versions"

#6 2008-11-16 20:24:48

Re: git/svn/cvs "versions"

Board footer