[oe] Use of github /archive/ tarballs in SRC_URI

Randy MacLeod randy.macleod at windriver.com
Tue Sep 19 17:02:48 UTC 2017


Add oe-core, oe-devel back after checking privately with Ross.

On 2017-09-19 12:38 PM, Burton, Ross wrote:
> On 19 September 2017 at 17:29, Randy MacLeod 
> <randy.macleod at windriver.com <mailto:randy.macleod at windriver.com>> wrote:
> 
>     On 2017-09-19 04:09 AM, Burton, Ross wrote:
> 
>         Then the tarball for one of Erlang's repositories changed, and
>         was noticed
>         by the checksum in the recipe (thanks Gunnar Andersson for reporting
>         this).  The extracted contents are identical, but the tarball
>         itself has
>         changed.  I'm presuming this is due to the old tarball expiring
>         in their
>         cache, and a newly generated tarball using a later version of tar.
> 
>         So we now have documented evidence that this can and does
>         happen, and it's
>         quite frustrating when this happens.  So, I suggest that use of
>         github.com <http://github.com>
>         /archive/  URLs be considered a bad practise for the primary
>         SRC_URI tarball.
> 
> 
>     Agreed but it's a shame to have to deal with this as users rather
>     than have github fix the problem.
> 
>     Could report a bug if it's not already known?
>     https://github.com/contact
> 
> 
> They know, and don't commit to the /archive/ tarballs being persistent.  
> They're for convenience and if the project owner wants a stable tarball 
> they should upload one (that's almost quoted verbatim from my mails with 
> github).
> 
> Last time I looked they were generated on demand using git-archive and 
> cached for "some time" on AWS.  If nobody access the tarball for a while 
> it will fall off AWS and then be re-generated.  The output from 
> git-archive will be identical but eg a new tar may write a different 
> byte stream for the same input.

Ugh, but I guess it makes sense from their point of view since
they're all about the git repos.

Thanks for the background info Ross,

-- 
# Randy MacLeod.  WR Linux
# Wind River an Intel Company



More information about the Openembedded-devel mailing list