Difference between revisions of "Talk:VCS package guidelines"

From ArchWiki
Jump to: navigation, search
(More on git pkgver()'s)
(More on git pkgver()'s)
Line 76: Line 76:
:::--[[User:Det|Det]] ([[User talk:Det|talk]]) 20:44, 14 May 2013 (UTC)
:::--[[User:Det|Det]] ([[User talk:Det|talk]]) 20:44, 14 May 2013 (UTC)
::::Why not make the change for use {{ic|.r}} or {{ic|~}} instead from the actual {{ic|.}} for prevent that problem --[[User:Jristz|Jristz]] ([[User talk:Jristz|talk]]) 18:52, 17 May 2013 (UTC)
::::Why not make the change for use {{ic|.r}} or {{ic|~}} instead from the actual {{ic|.}} for prevent that problem
::::--[[User:Jristz|Jristz]] ([[User talk:Jristz|talk]]) 18:52, 17 May 2013 (UTC)
:::::Well, that's what's being suggested.. --[[User:Det|Det]] ([[User talk:Det|talk]]) 05:57, 19 May 2013 (UTC)
:::::Well, that's what's being suggested..
:::::--[[User:Det|Det]] ([[User talk:Det|talk]]) 05:57, 19 May 2013 (UTC)
== Clarifying the first Git function ==
== Clarifying the first Git function ==

Revision as of 05:57, 19 May 2013

https:// vs git://

Could we consider a guideline to use firewall-friendly protocols when possible (e.g. https://github.com/matplotlib/matplotlib.git instead of git://github.com/matplotlib/matplotlib.git)? --Mitch feaster 14:34, 15 November 2011 (EST)

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.
--Det (talk) 22:51, 2 May 2013 (UTC)

Updating a CVS repo

I don't use cvs. How can you describe the pkgver for cvs (for pacman 4.1)?
-- Dracorp (talk) 09:31, 6 April 2013 (UTC)

CVS is not supported in pacman 4.1 like the other VCS tools. You will need to update pkgver manually until CVS support is added.
-- Jstjohn (talk) 22:44, 15 April 2013 (UTC)
Yeah, but how about mentioning that in the article (as well as giving a download example)? Even if it's not that common anymore.
--Det (talk) 22:39, 2 May 2013 (UTC)
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?
-- Scimmia (talk) 07:17, 15 May 2013 (UTC)
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.
--Det (talk) 05:54, 19 May 2013 (UTC)

Checking out branches/tags needs clarification

The #fragment part of the VCS source URL has a different meaning for each type of VCS. 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)

check out branch git_test of git://myproject.com into folder my_git_code :


Check out branch svn_test of svn://myproject.com into folder my_svn_code :


Lone_Wolf (talk) 20:49, 16 April 2013 (UTC)

Makes sense. At least for those two.
--Det (talk) 22:53, 2 May 2013 (UTC)

More on git pkgver()'s

I would also like to see packages use pkgver functions like this:

git describe --always --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g'

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

current ver: next ver:

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:

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

KaiSforza (talk) 20:42, 18 April 2013 (UTC)

So Git makes some projects jump down from x.x.x.210 to x.x.x.x.50? Is that really intended behavior?
--Det (talk) 22:48, 2 May 2013 (UTC)
Yes, that's intended behavior. That number is the number of commits since the last tag, so it will reset every time the author tags a new commit.
Scimmia (talk) 08:02, 4 May 2013 (UTC)
I noticed just now there's the .1.
--Det (talk) 20:44, 14 May 2013 (UTC)
Why not make the change for use .r or ~ instead from the actual . for prevent that problem
--Jristz (talk) 18:52, 17 May 2013 (UTC)
Well, that's what's being suggested..
--Det (talk) 05:57, 19 May 2013 (UTC)

Clarifying the first Git function

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

Also the output should be something like 2.0.6.a17a017 to include the $(git rev-parse --short HEAD) part for clarification.


pkgver() {
  cd local_repo
  git describe --always | cut -d "-" -f2- | tr - .
Note: See the man pages of cut(1) and tr(1) for more info.

--Det (talk) 00:22, 3 May 2013 (UTC)

Did you test this before posting? It doesn't do anything like you think it does. Scimmia (talk) 22:29, 4 May 2013 (UTC)
Well, my friend, that's what makes it an example. The reason I'm using cut is to remove the actual project names that are often included in their tags. All the sed example does is change the hyphens (-) to dots (.), which is simpler to do with 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 $ 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.
--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. Scimmia (talk) 02:15, 8 May 2013 (UTC)
That only works when they do. It doesn't remove the names from the tags, which are included in things like Wine and the entire X stack.
git describe --always | sed 's/\([^0-9]*\)\(.*\)/\2/g; s/-/./g' is the most universal approach I can think of. But it's unreadable and a lot harder to edit than some cut/tr combination.
--Det (talk) 20:37, 14 May 2013 (UTC)
Yeah, my example was a special case as well. I'm really thinking that this is a situation where it's best just to include a very simple example and let the maintainer customize it as needed instead of trying to find a convoluted solution that works everywhere.
-- Scimmia (talk) 07:11, 15 May 2013 (UTC)