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

[Dave Reisner]

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_Guidelines for
> >> 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.