:It shouldn't be too hard to just mention that. As I haven't heard of anybody else ever bringing it up, it'd probably be enough.

:It shouldn't be too hard to just mention that. As I haven't heard of anybody else ever bringing it up, it'd probably be enough.

Line 17:

Line 17:

::--[[User:Det|Det]] ([[User talk:Det|talk]]) 22:39, 2 May 2013 (UTC)

::--[[User:Det|Det]] ([[User talk:Det|talk]]) 22:39, 2 May 2013 (UTC)

−

== checking out branches/tags needs clarification ==

+

:::The download example can still be found in {{ic|/usr/share/pacman/}}. The next version of the ABS package should update it a bit so the download happens in the prepare function where it belongs. As for pkgver, I think the generic example using date covers that, as there's not a way to get a version number from a CVS repo. Maybe a note to that effect?

The {{ic|#fragment}} part of the VCS source URL has a different meaning for each type of VCS.

+

::::That makes the most sense, but it might also be a good idea to rename the [[VCS PKGBUILD Guidelines#Fallback|"Fallback"]] section to something like "Fallback / CVS" to make it more obvious even when you're just checking out the table of contents.

−

This can be confusing for people, especially when they are trying to checkout a specific branch or tag.

+

−

Examples would reduce the chance for confusion a lot.

+

−

fictional examples for git and svn (don't have experience with bzr or HG)

+

::::But as for ABS, as far as I can tell the last commit was over [https://projects.archlinux.org/abs.git/log/ 8 months] ago.

check out branch {{ic|git_test}} of git://myproject.com into folder {{ic|my_git_code}} :

+

:::::Hmm, there were a number of patches submitted last month for cleaning up the prototypes, looks like none have been committed yet. I do remember a discussion (IRC maybe?) questioning the proper place for the prototypes, so maybe that's why? Looking at the patches, I was mistaken anyway; they didn't update the darcs or cvs prototypes. Simple enough, I'll send in a patch myself.

Instead of just {{ic|<nowiki>sed 's|-|.|g'</nowiki>}} it'd probably be better to give some example with {{ic|cut}} (which you're probably gonna end up using anyway) and {{ic|tr}} (which is simpler than {{ic|sed}}). Then you could either explain it like this or just mention the man pages: ''"{{ic|cut -d "-" -f2-}} cuts from the first hyphen (-) to the end, {{ic|tr - .}} converts hyphens to dots (.) and {{ic|tr -d -}} removes the hyphens"''.

:I have the same issue with {{AUR|tup-git}} package that bumped its version from {{ic|0.6}} to {{ic|0.6.5}}. previously generated version was {{ic|0.6.350.gfoobar}} now it became {{ic|0.6.5}} that is smaller than previous. Generated version should split upstream version from {{ic|git describe}} version. My vote is goes to {{ic|~}} delimiter proposed above. Or maybe we can use {{ic|-}} as delimiter?

:::{{ic|r}} prefix is fine with me. We also need to cut leading {{ic|v}} from the version returned by git. Here is slightly modified {{ic|pkgver()}} used by {{AUR|tup-git}} package {{ic|<nowiki>git describe | sed -E 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'</nowiki>}}

{{Note|See the man pages of [http://unixhelp.ed.ac.uk/CGI/man-cgi?cut cut(1)] and [http://unixhelp.ed.ac.uk/CGI/man-cgi?tr+1 tr(1)] for more info.}}

−

--[[User:Det|Det]] ([[User talk:Det|talk]]) 00:22, 3 May 2013 (UTC)

−

:Did you test this before posting? It doesn't do anything like you think it does. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 22:29, 4 May 2013 (UTC)

+

Please could this be included in the page.

−

::Well, my friend, that's what makes it an ''example''. The reason I'm using {{ic|cut}} is to remove the actual project names that are often included in their tags. All the sed example does is change the hyphens ({{ic|-}}) to dots ({{ic|.}}), which is simpler to do with {{ic|tr - .}} anyway.

::What _makes_ it so hard is that there ''isn't'' a single solution that somehow magicly worked on all scenarios. Even if you decided to be clever and started cutting the output up until the first number (with something like {{ic|$ sed 's/\([^0-9]*\)\(.*\)/\2/g'}}), you'd still end up with the wrong result whenever the "version" starts with a letter or the project name ends with a number.

+

== git pkgver: Date of last commit at the beginning of the version number for compatibility with older PKGBUILDs from AUR? ==

−

::--[[User:Det|Det]] ([[User talk:Det|talk]]) 21:04, 7 May 2013 (UTC)

+

−

:::Ah, I see now, you were addressing a special case. You're right, there ''isn't'' a single solution. You're also right that tr is simpler and should probably be used in the example if that's all the example is going to show. It seems to be fairly common, though, to include a "v" at the beginning of the version number, in which case you'd already be using sed anyway so you can just do sed 's/^v//;s/-/./g' So many ways of doing the same job. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 02:15, 8 May 2013 (UTC)

+

We have quite a bunch of older PKGBUILDs for -git packages in AUR which still work but which do not have a pkgver function yet. Many of these actually carry a date as version number (mostly the date of the last git commit at the time when the PKGBUILD was last updated).

−

== Edit or remove "Removing VCS leftovers" section ==

+

When you update these scripts to use one of the two pkgver functions suggested on the wiki page, AUR helpers like packer will (in most cases) suggest that there is a newer version in AUR on every system update. My proposal to solve this problem is a pkgver function which precedes the generated version number with the date of the last git commit:

−

This section is meant for people who look in {{ic|$pkgdir}} and see that the {{ic|.git}} or {{ic|.svn}} dir is there for some reason. What's actually happening is that people are adding it to their PKGBUILDs for no reason at all, not realizing what it's for. Honestly, has anyone seen an installer that installs the VCS dir? IMO, this section should just be removed, but if it needs to be kept, it should be clarified somehow so that people realize that it only needs to be used in very rare circumstances.

:I agree that back when I was clarifying that thing I didn't think there was really a single package even using it, but since somebody decided to include it, I let it be.

+

This function is *not* intended to go into PKGBUILDs in AUR, but could be proposed as a temporary "local" fix in the wiki for the period of time until the package maintainer has found time to update his PKGBUILD in AUR.

The "SVN packages that try to get their revision number" and "Bazaar limitation" sections should be able to be deleted now. We can also change the cd in the svn pkgver() example to match the others and get rid of the note.

The download example can still be found in /usr/share/pacman/. The next version of the ABS package should update it a bit so the download happens in the prepare function where it belongs. As for pkgver, I think the generic example using date covers that, as there's not a way to get a version number from a CVS repo. Maybe a note to that effect?

That makes the most sense, but it might also be a good idea to rename the "Fallback" section to something like "Fallback / CVS" to make it more obvious even when you're just checking out the table of contents.

But as for ABS, as far as I can tell the last commit was over 8 months ago.

Hmm, there were a number of patches submitted last month for cleaning up the prototypes, looks like none have been committed yet. I do remember a discussion (IRC maybe?) questioning the proper place for the prototypes, so maybe that's why? Looking at the patches, I was mistaken anyway; they didn't update the darcs or cvs prototypes. Simple enough, I'll send in a patch myself.

More on git pkgver()'s

so they are more friendly to vercmp.
Current behaviour using git-git as an example:

current ver: 1.8.2.210.g123abc-1
next ver: 1.8.2.1.50.g123abc-1

vercmp 1.8.2.210.g123abc 1.8.2.1.50.g123abc
1 # the first is greater than the second

Right now, the current version is actually greater than the new version, causing a downgrade. If r is appended to the patch level (the numbers just before the g<hex> bit), then vercmp would order the versions correctly.

current ver: 1.8.2.r210.g123abc-1
next ver: 1.8.2.1.r50.g123abc-1

vercmp 1.8.2.r210.g123abc 1.8.2.1.r50.g123abc
-1 # the first is less than the second

I have the same issue with tup-gitAUR package that bumped its version from 0.6 to 0.6.5. previously generated version was 0.6.350.gfoobar now it became 0.6.5 that is smaller than previous. Generated version should split upstream version from git describe version. My vote is goes to ~ delimiter proposed above. Or maybe we can use - as delimiter?

r prefix is fine with me. We also need to cut leading v from the version returned by git. Here is slightly modified pkgver() used by tup-gitAUR package git describe | sed -E 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'

git pkgver: Date of last commit at the beginning of the version number for compatibility with older PKGBUILDs from AUR?

We have quite a bunch of older PKGBUILDs for -git packages in AUR which still work but which do not have a pkgver function yet. Many of these actually carry a date as version number (mostly the date of the last git commit at the time when the PKGBUILD was last updated).

When you update these scripts to use one of the two pkgver functions suggested on the wiki page, AUR helpers like packer will (in most cases) suggest that there is a newer version in AUR on every system update. My proposal to solve this problem is a pkgver function which precedes the generated version number with the date of the last git commit:

This function is *not* intended to go into PKGBUILDs in AUR, but could be proposed as a temporary "local" fix in the wiki for the period of time until the package maintainer has found time to update his PKGBUILD in AUR.