On Fri, Jan 24, 2014 at 09:00:34PM +0100, Maxime Gauduin wrote: > On Fri, Jan 24, 2014 at 7:23 PM, Dave Reisner <[email protected]> wrote: > > > On Tue, Nov 05, 2013 at 10:59:59AM +1000, Allan McRae wrote: > > > On 02/11/13 03:14, Maxime Gauduin wrote: > > > > On Fri, Nov 1, 2013 at 2:42 AM, William Giokas <[email protected]> > > wrote: > > > > > > > >> On Fri, Nov 01, 2013 at 11:33:31AM +1000, Allan McRae wrote: > > > >>> I am proposing we include this PKGBUILD-vcs.proto into pacman (after > > > >>> removing the pointer to the Arch wiki). > > > >>> > > > >>> Comments? > > > >>> > > > >>> Allan > > > >>> > > > >>> > > > >>> -------- Original Message -------- > > > >>> Subject: [arch-projects] [ABS] [PATCHv2] Merge bzr, git, hg and svn > > into > > > >>> a generic proto > > > >>> Date: Tue, 8 Oct 2013 16:13:25 +0200 > > > >>> From: Maxime Gauduin <[email protected]> > > > >>> Reply-To: Arch Linux projects development discussion > > > >>> <[email protected]> > > > >>> To: [email protected] > > > >>> > > > >>> Having separate prototypes for each VCS type is no longer relevant > > since > > > >>> Pacman 4.1. Having a generic prototype for regular, bzr, git hg and > > svn > > > >>> packages makes more sense. Left cvs, and darcs protos untouched as > > they > > > >>> are not yet supported in Pacman. > > > >>> > > > >>> Signed-off-by: Maxime Gauduin <[email protected]> > > > >>> --- > > > >>> prototypes/PKGBUILD-bzr.proto | 64 ---------------------------- > > > >>> prototypes/PKGBUILD-git.proto | 64 ---------------------------- > > > >>> prototypes/PKGBUILD-hg.proto | 65 ---------------------------- > > > >>> prototypes/PKGBUILD-svn.proto | 63 ---------------------------- > > > >>> prototypes/PKGBUILD-vcs.proto | 98 > > > >>> +++++++++++++++++++++++++++++++++++++++++++ > > > >>> 5 files changed, 98 insertions(+), 256 deletions(-) > > > >>> delete mode 100644 prototypes/PKGBUILD-bzr.proto > > > >>> delete mode 100644 prototypes/PKGBUILD-git.proto > > > >>> delete mode 100644 prototypes/PKGBUILD-hg.proto > > > >>> delete mode 100644 prototypes/PKGBUILD-svn.proto > > > >>> create mode 100644 prototypes/PKGBUILD-vcs.proto > > > >>> > > > >>> <snip> > > > >>> > > > >>> diff --git a/prototypes/PKGBUILD-vcs.proto > > > >> b/prototypes/PKGBUILD-vcs.proto > > > >>> new file mode 100644 > > > >>> index 0000000..805f4ff > > > >>> --- /dev/null > > > >>> +++ b/prototypes/PKGBUILD-vcs.proto > > > >>> @@ -0,0 +1,98 @@ > > > >>> +# This is an example PKGBUILD file. Use this as a start to creating > > > >>> your own, > > > >>> +# and remove these comments. For more information, see 'man > > PKGBUILD'. > > > >>> +# NOTE: Please fill out the license field for your package! If it is > > > >>> unknown, > > > >>> +# then please put 'unknown'. > > > >>> + > > > >>> +# The following guidelines are specific to BZR, GIT, HG and SVN > > > >> packages. > > > >>> +# CVS and DARCS are not natively supported in pacman yet, please > > refer > > > >>> to the > > > >>> +# dedicated prototypes instead. > > > >>> +# See http://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelinesfor > > > >> more > > > >>> +# information on packaging from VCS sources. > > > >>> + > > > >>> +# Maintainer: Your Name <[email protected]> > > > >>> +pkgname=NAME-VCS # '-bzr', '-git', '-hg' or '-svn' > > > >>> +pkgver=VERSION > > > >>> +pkgrel=1 > > > >>> +pkgdesc="" > > > >>> +arch=() > > > >>> +url="" > > > >>> +license=('GPL') > > > >>> +groups=() > > > >>> +depends=() > > > >>> +makedepends=('VCS_PACKAGE') # 'bzr', 'git', 'mercurial' or > > 'subversion' > > > >>> +provides=("${pkgname%-VCS}") > > > >>> +conflicts=("${pkgname%-VCS}") > > > >>> +replaces=() > > > >>> +backup=() > > > >>> +options=() > > > >>> +install= > > > >>> +source=('DIR_NAME::VCS+REPO_URL#FRAGMENT') > > > >>> +noextract=() > > > >>> +md5sums=('SKIP') > > > >>> + > > > >>> > > > >> > > +################################################################################ > > > >>> + > > > >>> +# DIR_NAME: Use to change the source directory name if needed > > > >>> + > > > >>> +# VCS: Use to specify the VCS type, not needed when REPO_URL is > > > >>> explicit (for > > > >>> +# example git://URL, svn://URL or lp:NAME) > > > >>> + > > > >>> +# FRAGMENT: Use to pull a specific branch, commit/revision or tag > > > >>> +# Bazaar accepts the 'revision' keyword > > > >>> +# Git accepts the 'branch', 'commit' and 'tag' keywords > > > >>> +# Mercurial accepts the 'branch', 'revision' and 'tag' keywords > > > >>> +# Subversion accepts the 'revision' keyword > > > >>> + > > > >>> +# Examples: > > > >>> +# source=("lp:${pkgname%-bzr}#revision=42") > > > >>> +# > > > >>> source=("git+ > > > >> https://github.com/author/${pkgname%-git}.git#branch=unstable";) > > > >>> +# source=('hg+https://bitbucket.org/author/project#tag=2.0') > > > >>> +# source=("${pkgname%-svn}::svn:// > > svn.code.sf.net/p/project/code/trunk > > > >> "} > > > >>> + > > > >>> > > > >> > > +################################################################################ > > > >>> + > > > >>> +pkgver() { > > > >>> + cd "$srcdir/${pkgname%-VCS}" > > > >>> + > > > >>> +# Bazaar > > > >>> + printf "%s" "$(bzr revno)" > > > >>> + > > > >>> +# Git, tags available > > > >>> + printf "%s" "$(git describe --long | sed 's/-/./g')" > > > >>> + > > > >>> +# Git, no tags available > > > >>> + printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse > > > >>> --short HEAD)" > > > >>> + > > > >>> +# Mercurial > > > >>> + printf "%s.%s" "$(hg identify -n)" "$(hg identify -i)" > > > >>> + > > > >>> +# Subversion > > > >>> + printf "%s" "$(svnversion | tr -d 'A-z')" > > > >>> + > > > >>> +# Fallback > > > >>> + printf "%s" "$(date +%Y%m%d)" > > > >>> +} > > > >> > > > >> Do not include this. There has been a lot of discussion about what is > > > >> right for this, and I would say that it's best to leave this as a > > > >> commented out function. The user creating the PKGBUILD should tailor > > > >> this to the VCS and package they are using. > > > >> > > > >> > > > > > > > > Can't we leave some as examples? I agree they're in no way absolute > > rules > > > > because they can't fit every situation, but still they're a starting > > point. > > > > > > > > > > I initially thought that the "do not include this" was referring to the > > > fallback. That I could agree with removing, but not the entire function. > > > > > > Allan > > > > > > > Resurrecting this as it doesn't seem there was a conclusion to this or > > patched merged, and I've decided to care about ABS today. > > > > Can we keep the examples but add a disclaimer that these are examples > > only and they need to be appropriate for that specific repo? > > > > On the other hand, I take specific exception with your "Git, no tags > > available" example because it *usually* leads to a need for an epoch > > increase once the repository has tags. Because of the social stigma > > surrounding the use of epoch, we shouldn't encourage this. > > > > > > > Disclaimer sounds good. Also, I've started adding a 'r' before the > rev/commit number as suggested in the wiki [1]. Since numbers take > precedence over letters, we wouldn't need to introduce an epoch when tags > are created. What do you think?
Sure, this looks like a good idea.
