[pacman-dev] Fwd: [arch-projects] [ABS] [PATCHv2] Merge bzr, git, hg and svn into a generic proto

Fri Jan 24 15:18:34 EST 2014

On Fri, Jan 24, 2014 at 09:00:34PM +0100, Maxime Gauduin wrote:
> On Fri, Jan 24, 2014 at 7:23 PM, Dave Reisner <d at falconindy.com> 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 <1007380 at gmail.com>
> > 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 <alucryd at gmail.com>
> > > >>> Reply-To: Arch Linux projects development discussion
> > > >>> <arch-projects at archlinux.org>
> > > >>> To: arch-projects at archlinux.org
> > > >>>
> > > >>> 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 <alucryd at gmail.com>
> > > >>> ---
> > > >>>  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 <youremail at domain.com>
> > > >>> +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.