From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S6nJi-0006Ik-SI for garchives@archives.gentoo.org; Sun, 11 Mar 2012 18:16:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 26DB5E0953; Sun, 11 Mar 2012 18:16:18 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E18C2E094B for ; Sun, 11 Mar 2012 18:15:53 +0000 (UTC) Received: from [192.168.26.5] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 3CCDB1B403F for ; Sun, 11 Mar 2012 18:15:53 +0000 (UTC) Message-ID: <4F5CEBD6.4060206@gentoo.org> Date: Sun, 11 Mar 2012 11:15:50 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120304 Thunderbird/10.0.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: an eclass for github snapshots? References: <3869551.77.1331486738371.JavaMail.geo-discussion-forums@vbhy1> In-Reply-To: <3869551.77.1331486738371.JavaMail.geo-discussion-forums@vbhy1> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c9258337-320f-41cf-b940-d0f39160eab4 X-Archives-Hash: 05ebd84f31b4f7813593468b2b81653d On 03/11/2012 10:25 AM, Leho Kraav wrote: > On Monday, May 30, 2011 9:30:02 AM UTC+3, Micha=C5=82 G=C3=B3rny wrote: >> >> Right now, a quick 'grep -l github.*tarball' shows that there are abou= t >> 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 providin= g >> github_src_unpack() for EAPIs 2+. >=20 > What is the current situation with this one? Every once in a while I ru= n into a github ebuild I need to create and I am not really sure what to = do with it. >=20 > Right now 2) seems like the safest approach. But did anything get into = EAPI? No, there's no EAPI extension for that yet, and no bug filed for it here: https://bugs.gentoo.org/show_bug.cgi?id=3D174380 --=20 Thanks, Zac