Re: [gentoo-dev] RFC: an eclass for github snapshots?

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2059 bytes --]

On Mon, 12 Mar 2012 09:36:00 +0800
Ben <yngwin@gmail.com> wrote:

> On 12 March 2012 02:27, Michał Górny <mgorny@gentoo.org> wrote:
> > On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
> > Leho Kraav <leho@kraav.com> wrote:
> >
> >> On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
> >> >
> >> > Right now, a quick 'grep -l github.*tarball' shows that there are
> >> > about 147 ebuilds in portage using github snapshots. This
> >> > evaluates to 83 different packages.
> >> >
> >> > The problem with github is that it suffixes the tarballs with
> >> > a complete git commit id. This means that the `S' variable
> >> > in the ebuild needs to refer to a long hash changing randomly.
> >> > Right now, the problem is handled in a number of ways:
> >> >
> >> > 1) (from app-admin/rudy)
> >> > 2) (app-emacs/calfw and suggested solution for Sunrise)
> >> > 3) (app-misc/bgrep)
> >> > 4) (app-misc/tmux-mem-cpu-load)
> >> >
> >> > What I'd like to do is creating a small github.eclass,
> >> > encapsulating a common, nice way of handling the S issue. I
> >> > guess the best solution would be to git with something like 2)
> >> > above, with the eclass providing github_src_unpack() for EAPIs
> >> > 2+.
> >>
> >> What is the current situation with this one? Every once in a while
> >> I run into a github ebuild I need to create and I am not really
> >> sure what to do with it.
> >>
> >> Right now 2) seems like the safest approach. But did anything get
> >> into EAPI?
> >
> > You mean eclass? I submitted one for review but didn't get much of
> > positive feedback on it. I'll commit it anyway soon, just let me
> > double check and do some testing.
> 
> +1 from me. I think it would be useful to have a standard way of
> handling this.

Attaching my current conceptual eclass. I've tested it with github,
gitweb and bitbucket. It won't work with gitorious but their snapshot
download mechanism is broken anyway (they like to submit 'try again
later' in plaintext).

-- 
Best regards,
Michał Górny

[-- Attachment #1.2: vcs-snapshot.eclass --]
[-- Type: text/plain, Size: 1419 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: vcs-snapshot.eclass
# @MAINTAINER:
# mgorny@gentoo.org
# @BLURB: support eclass for VCS (github, bitbucket, gitweb) snapshots
# @DESCRIPTION:
# This eclass provides a convenience src_unpack() which does support
# working with snapshots generated by various VCS-es. It unpacks those
# to ${S} rather than the original directory containing commit id.
#
# Note that this eclass handles only unpacking. You need to specify
# SRC_URI yourself, and call any autoreconfiguration as necessary.
# The example does that using autotools-utils eclass.
#
# Right now, the eclass was tested with github, bitbucket and gitweb
# snapshots. Feel free to report snapshotting services which aren't
# working.
# @EXAMPLE:
#
# @CODE
# EAPI=4
# AUTOTOOLS_AUTORECONF=1
# inherit autotools-utils vcs-snapshot
#
# SRC_URI="http://github.com/example/${PN}/tarball/v${PV} -> ${P}.tar.gz"
# @CODE

case ${EAPI:-0} in
	0|1) die "EAPI ${EAPI} unsupported.";; # default(), SRC_URI arrows
	2|3|4) ;;
	*) die "github-snapshot.eclass API in EAPI ${EAPI} not yet established."
esac

EXPORT_FUNCTIONS src_unpack

vcs-snapshot_src_unpack() {
	default

	# github, bitbucket: username-projectname-hash
	# gitweb: projectname-tagname-hash
	mv *-*-[0-9a-f]*[0-9a-f]/ "${S}" || die
}

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]