Difference between revisions of "Talk:VCS package guidelines"

From ArchWiki
Jump to: navigation, search
(Sed -> tr: new section)
(36 intermediate revisions by 14 users not shown)
Line 1: Line 1:
Q: Any reason for using 'svn co' instead of 'svn export'? export is way faster for these situations and it doesn't create all the .svn files.
+
== https:// vs git:// ==
  
A: Look at http://bbs.archlinux.org/viewtopic.php?pid=245213
+
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)?
 +
--[[User:Mitch feaster|Mitch feaster]] 14:34, 15 November 2011 (EST)
  
----
+
== Updating a CVS repo ==
 +
I don't use cvs. How can you describe the pkgver for cvs (for pacman 4.1)? <br>
 +
-- [[User:Dracorp|Dracorp]] ([[User talk:Dracorp|talk]]) 09:31, 6 April 2013 (UTC)
  
Just wondering if the versionpkg part will be removed - I hear that makepkg now has versionpkgs functionality...
+
: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.
--[[User:Ak5|ak5]] 16:55, 8 June 2008 (EDT)
+
:-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 22:44, 15 April 2013 (UTC)
  
-- done (wide-eye)
+
== 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.
  
The title for this article indicate guidelines for CVS and SVN, but git and darcs are also included. Perhaps the title should be changed to reflect this, or git and darcs guidelines should be separated off into their own articles. --[[User:Mentallaxative|mentallaxative]] 01:48, 18 October 2008 (EDT)
+
fictional examples for git and svn (don't have experience with bzr or HG)
  
-- I agree. --[[User:Matthewbauer|Matthewbauer]] 17:16, 21 July 2009 (EDT)
+
check out branch git_test of git://myproject.com into folder my_git_code :
 +
my_git_code::git://myproject.com/#branch=git_test
  
-- done --[[User:Shining|shining]] 07:59, 4 October 2009 (EDT)
+
Check out branch svn_test of svn://myproject.com into folder my_svn_code :
 +
my_svn_code::svn://myproject.com/branches/svn_test
  
----
+
[[User:Lone Wolf|Lone_Wolf]] ([[User talk:Lone Wolf|talk]]) 20:49, 16 April 2013 (UTC)
  
What's the reason for using 'cp -r $_svnmod $_svnmod-build' instead of using 'svn export $_svnmod $_svnmod-build'?--[[User:BertiBoeller|BertiBoeller]] 19:21, 15 March 2009 (EDT)
+
== pkgver() for git ==
  
-- no reason afaik. Please send a patch against /usr/share/pacman/PKGBUILD-svn.proto from abs package to the bug tracker. --[[User:Shining|shining]] 07:59, 4 October 2009 (EDT)
+
I'd like to suggest using HEAD instead of master in example pkgver(), i.e.
 +
{{bc|
 +
pkgver() {
 +
  cd local_repo
 +
  echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD)
 +
}
 +
}}
 +
instead of
 +
{{bc|
 +
pkgver() {
 +
  cd local_repo
 +
  echo $(git rev-list --count master).$(git rev-parse --short master)
 +
}
 +
}}
  
----
+
Pros:
 +
If source line contains fragment, e.g. {{ic|source&#61;("$pkgname::git://path.git#branch&#61;name")}}, offered version will not work correct. User may forget to fix it (from master to specified branch or commit). My version lacks this bug.
  
Does the AUR still reject PKGBUILDs without a source=() and md5sum=() field? I don't think so - I have many PKGBUILDs up without them. [[User:Alex anthony|Alex anthony]] 20:29, 12 August 2009 (EDT)
+
Cons:
 +
Don't see. But I'd like this fix to be reviewed if I miss something. Bug in such example may hurt many package maintainers.
  
-- I updated the page accordingly. --[[User:Shining|shining]] 07:59, 4 October 2009 (EDT)
+
== More on git pkgver()'s ==
  
----
+
I would also like to see packages use pkgver fucntions like this:
  
Please submit the Mercurial proto to flyspray so that it can be added to abs package.
+
git describe --always --long | sed -E 's/([^-]*-g)/r\1/;s/-/./g'
--[[User:Shining|shining]] 17:37, 18 December 2009 (EST)
+
  
 +
so they are more friendly to vercmp.
 +
Current behaviour using git-git as an example:
  
PROPOSAL:
+
current ver: {{ic|1.8.2.210.g123abc-1}}
---------
+
next ver: {{ic|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
  
Change the guideline about naming packages xxx-git or xxx-svn or xxx-whatever to a much less confusing and generic xxx-vcs.
+
Right now, the current version is actually greater than the new version, causing a downgrade. If {{ic|r}} is appended to the patch level (the numbers just before the g<hex> bit), then vercmp would order the versions correctly.
  
- less confusing
+
current ver: {{ic|1.8.2.r210.g123abc-1}}
- if package developer changes vcs, the package name will change = more confusion and redundant packages lying around
+
next ver: {{ic|1.8.2.1.r50.g123abc-1}}
- causes unrelible dependencies whereas depends on 'xxx-vcs' will not change = big mess avoided
+
vercmp 1.8.2.r210.g123abc 1.8.2.1.r50.g123abc
- same goes for conflicts.
+
-1 # the first is less than the second
- who cares which vcs is used anyway? All the end user needs to know is that it from vcs as opposed to a fixed release.
+
  
anybody got something against this idea?
+
[[User:KaiSforza|KaiSforza]] ([[User talk:KaiSforza|talk]]) 20:42, 18 April 2013 (UTC)
 +
 
 +
== Sed -> tr ==
 +
 
 +
{{ic|<nowiki>sed 's|-|.|g'</nowiki>}}'s could be replaced with just {{ic|tr - .}}'s as well. --[[User:Det|Det]] ([[User talk:Det|talk]]) 13:10, 2 May 2013 (UTC)

Revision as of 13:10, 2 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)

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)

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 :

my_git_code::git://myproject.com/#branch=git_test

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

my_svn_code::svn://myproject.com/branches/svn_test

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

pkgver() for git

I'd like to suggest using HEAD instead of master in example pkgver(), i.e.

pkgver() {
  cd local_repo
  echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD)
}

instead of

pkgver() {
  cd local_repo
  echo $(git rev-list --count master).$(git rev-parse --short master)
}

Pros: If source line contains fragment, e.g. source=("$pkgname::git://path.git#branch=name"), offered version will not work correct. User may forget to fix it (from master to specified branch or commit). My version lacks this bug.

Cons: Don't see. But I'd like this fix to be reviewed if I miss something. Bug in such example may hurt many package maintainers.

More on git pkgver()'s

I would also like to see packages use pkgver fucntions 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: 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

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

Sed -> tr

sed 's|-|.|g''s could be replaced with just tr - .'s as well. --Det (talk) 13:10, 2 May 2013 (UTC)