On Mon, 12 Mar 2012 10:47:41 +0100 Michał Górny <mgo...@gentoo.org> wrote:
> On Mon, 12 Mar 2012 09:36:00 +0800 > Ben <yng...@gmail.com> wrote: > > > On 12 March 2012 02:27, Michał Górny <mgo...@gentoo.org> wrote: > > > On Sun, 11 Mar 2012 10:25:38 -0700 (PDT) > > > Leho Kraav <l...@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). Committed. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
