[OE-core] [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-core
mailing list