Date: Sat, 10 Sep 2011 18:33:30 +0100 From: Chris Rees <crees@freebsd.org> To: Baptiste Daroussin <bapt@freebsd.org> Cc: Lev Serebryakov <lev@freebsd.org>, freebsd-ports@freebsd.org, "Klaus T. Aehlig" <aehlig@linta.de> Subject: Re: [RFC] New ports idea: github / gitorious / bitbucket direct support. Message-ID: <CADLo83_Kk9FgdfAmKPEQT79oG%2BOqO7fDqy5RAbXGpwBCtjpdnA@mail.gmail.com> In-Reply-To: <20110909142857.GP31003@azathoth.lan> References: <765103585.20110909143052@serebryakov.spb.ru> <20110909130458.GO31003@azathoth.lan> <20110909132437.GA66311@kta1c10.sesnet.soton.ac.uk> <20110909142857.GP31003@azathoth.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 September 2011 15:28, Baptiste Daroussin <bapt@freebsd.org> wrote: > On Fri, Sep 09, 2011 at 02:24:37PM +0100, Klaus T. Aehlig wrote: >> > The main problem with that is: we have no way to keep a valid sum of t= he >> > distfiles if it is autogenerated (in particular with github) and this = sum is >> > really important. >> With github this fortunately is a non-issue. Even though they autogenera= te their >> tar balls, they keep enough information to make them reproduciable. Just= try: >> >> /tmp>fetch https://github.com/Dieterbe/uzbl/tarball/2011.07.25 >> 2011.07.25 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0100% of =A0143 kB =A0177 kBps >> /tmp>sha256 2011.07.25 >> SHA256 (2011.07.25) =3D 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a68884= 4ef921685dffe565 >> /tmp>cat /usr/ports/www/uzbl/distinfo >> SHA256 (uzbl-0.0.0.2011.07.25.tar.gz) =3D 2e61fa6c62e48d3f13e95a4ea7e7ae= ad65345f6c88a688844ef921685dffe565 >> SIZE (uzbl-0.0.0.2011.07.25.tar.gz) =3D 146851 >> /tmp> >> >> There still remain some minor issuses, like >> >> * due to autogeneration, you're quite likely to get a http-redirect, >> * filenames like 2011.07.25 are not too suitable for a distfile. >> >> But they certainly can be fixed by an appropriate framework. The nice th= ing is, >> github does the autogeneration right. >> >> Best, >> Klaus >> > > This is new because I already poke them about this in the past (more than= a year > ago and they clearly stated that they can't change that and that github p= eople > shouldn't use this for realease but should use the real download space of > github) > > The issue opened about this seems to have disapear from github, maybe the= y > change their mind > I agree 100% with Bapt here-- I had the same problem with security/gorilla (I think it was gorilla...) -- the tarball wasn't stable over time and I had many problems with distinfo. I solved the problem, as Bapt suggested by approaching the author and politely asking if he would host the tarball on github. He agreed to do this. Most of the time developers using github simply overlook the problems of autogenerated tarballs, and just don't think to host dedicated ones -- I've never had a negative response from upstream about providing a proper stable tarball. Counterexamples welcome! Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83_Kk9FgdfAmKPEQT79oG%2BOqO7fDqy5RAbXGpwBCtjpdnA>