[OpenWrt-Devel] openwrt/packages: [RFC] Regarding preferences re: switch to codeload

Daniel F. Dickinson cshored at thecshore.com
Mon Aug 13 14:15:06 EDT 2018


On 2018-08-13 01:45 PM, Rosen Penev wrote:

>> Furthermore I dislike the idea of tailoring download mechanisms around a
>> specific proprietary service.

This I agree with

>>
>> If the allegations about hash changes for unknown reasons are correct,
>> then this raises a huge red flag for me
> I can only imagine this to be the case if git history gets changed.
> I'm sure it's automated.

Well it's been happening intermittently for a least 2-3 years from what
I've seen myself and heard from others.  My own theory is a flaw in
their reproducible builds strategy, and for some reason or other
automated rebuilding of the tarballs even when the code hasn't changed.

>> and I see no reason to not
>> assume that codeload tarballs will eventually change as well, become
>> rate limited, redirected, discontinued or changed in other arbitrary ways.
> Well, there are people who believe Microsoft will cripple GitHub.

I don't MS is relevant to the question, only profit motive, TBH.  It's
more have a reasonable concern that the drive to monetize will result in
changes that make community more difficult (at best).

>>
>> So TLDR; I prefer a locally reproducible, cached tarball of a given SCM
>> clone over an opaque Github offer.
> It's not reproducible in all cases. See
> https://github.com/openwrt/openwrt/pull/815
> 
> We could not produce the same tarball with the same hash. I was using
> Ubuntu 16.04 FWIW

Can you reproduce the non-reproduction, or was it a one-off that could
be attribute temporary local issues?  I'm sure the OpenWrt core team
would really like to know about verifiable cases of issues with failures
to reproduce, since this is considered rather important.

>>
>>
>> My 2cents,
> Mine are that it's better to use a tarball that is not locally
> generated. I understand that ultimately the buildbots generate the
> tarballs but then you potentially have a situation where a package
> bump has the wrong hash since the buildbot and someone's local
> environment can differ enough to matter.

The whole point of the drive for reproducible builds (and tarballs) is
to identify all factors that influence the final hash and so that one
can be guaranteed of the same result irrespective of environment.  If
there is verifiable evidence somethings been missed, please file details
at https://bugs.openwrt.org as that's not just an issue with an
individual package but with the core system.

> 
> My understanding is that OpenWrt can be built on Linux and some BSDs
> like macOS or FreeBSD.
> 
> The initial motivation for moving packages to codeload was to adjust
> uscan's reporting of version numbers as git revisions when there are
> git tags available. eg: using
> 
> PKG_SOURCE_VERSION:=1ee4c4eac2f1f771ecc57d4f7ce298739bbc8a82 vs.
> PKG_SOURCE_VERSION:=v$(PKG_VERSION)

I'm not exactly convinced that's a good reason to adopt a tree-wide
change involving a propriety and opaque mechanism.

> 
> I also don't see why both codeload and buildbot generated tarballs
> can't coexist.

Have you looked at how the build system works in this regard?

Regards,

Daniel

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list