Talk:VCS package guidelines
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.
Just wondering if the versionpkg part will be removed - I hear that makepkg now has versionpkgs functionality... --ak5 16:55, 8 June 2008 (EDT)
-- done (wide-eye)
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. --mentallaxative 01:48, 18 October 2008 (EDT)
-- I agree. --Matthewbauer 17:16, 21 July 2009 (EDT)
-- done --shining 07:59, 4 October 2009 (EDT)
What's the reason for using 'cp -r $_svnmod $_svnmod-build' instead of using 'svn export $_svnmod $_svnmod-build'?--BertiBoeller 19:21, 15 March 2009 (EDT)
-- no reason afaik. Please send a patch against /usr/share/pacman/PKGBUILD-svn.proto from abs package to the bug tracker. --shining 07:59, 4 October 2009 (EDT)
Does the AUR still reject PKGBUILDs without a source=() and md5sum=() field? I don't think so - I have many PKGBUILDs up without them. Alex anthony 20:29, 12 August 2009 (EDT)
-- I updated the page accordingly. --shining 07:59, 4 October 2009 (EDT)
Please submit the Mercurial proto to flyspray so that it can be added to abs package. --shining 17:37, 18 December 2009 (EST)
Change the guideline about naming packages xxx-git or xxx-svn or xxx-whatever to a much less confusing and generic xxx-vcs.
- less confusing - if package developer changes vcs, the package name will change = more confusion and redundant packages lying around - causes unrelible dependencies whereas depends on 'xxx-vcs' will not change = big mess avoided - same goes for conflicts. - 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?