[LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency

[Daniel Golle]

Hi James,

On Tue, Mar 28, 2017 at 04:58:54PM -0600, James Feeney wrote:
> I am motivated to rant again on this topic.  Repeating what I said last
> November, before the new release process was finalized, in response to
> David Lang:
> 
> ---
> 
> >> There is an interesting question of how to refer to what state of each feed
> >> you use for a release. Currently OpenWRT doesn't even try to do this. The
> >> feed version you get is the feed version that exists at the time you last
> >> pulled from the feeds.
> 
> > Uhm - I'm a bit taken aback by that.

Well, this was actually fixed by having a specific snapshot of all
feeds referenced in the SDK. Which is exactly the cause of all the
confusion now...

> 
> >> This hasn't been a big problem in practice, but it does mean that you don't
> >> really have a repeatable build.
> 
> > I would have thought that that was a "show stopper".  It certainly does not
> > inspire confidence.
> 
> > I say this is a "problem" and should be a high priority issue.
> 
> >> See my other e-mail about [git] submodules for a
> >> discussion on this.
> 
> > Yes, I looked at that.  It would seem to address and solve a number of issues.
> > There would be no need for a separate "manifest", and, most importantly, there
> > would be a git "snapshot" of the *entire* project state.  If I understand,
> > that also means there would be a unique git tag that would label that state,
> > and could be associated with any kind of specific nickname, version, and build
> > number.  It would mean that every build was repeatable.

Every build of what exactly?
Do you realise that *none* of the packages from any of the feeds are
actually included in the released target binaries?
Strictly speaking the package feeds are simply not a part of the
project making the release.

> 
> >>> It would be possible, I suppose, that each of these linked repositories
> >>> could be *required* to use the *same* versioned naming scheme.
> >>
> >> can't be done, these other repositories are not under our control. The most
> >> we can do is reference exactly which release we use..
> 
> ---
> 
> So then, nothing was done to address this issue, when developing the new release
> process, where, instead, at worst, LEDE could simply "snapshot" a "feed", and
> keep that copy on github, and then *under LEDE's control*.  And git submodules
> are still an available solution.
> 
> I don't know that there is any polite way to express how ridiculous I find this
> situation, of non-repeatable builds, let alone the failure to bump the version
> number of the release.  I might call it "unprofessional", though I'm tempted to
> be otherwise demeaning.
> 
> Let me say again, I think that this is an important issue that the LEDE project
> needs to address and remedy.  I believe that the ultimate credibility and
> reputation of the LEDE project is at stake.

>From my understanding the original issue which was brought up by Pau
is the result of a lack of documentation how to properly use the SDK
and ImageBuilder. It doesn't have much too do with that past trauma
of yours, though obviously resembled it closely enough to trigger some
painful memories and write an email using lots of quotation marks and
emphasis to make us *see* "something".

Release builds (ie. building the buildroot from source) are entirely
reproducible, thanks to the long and tideous efforts of the
reproducible builds team, eliminating timestamps and other obstacles.
I fail to see the issue which would even remotely justifies the degree
of inflated drama. I fail to see how this is unprofessional or even
inconsistent or anything like that. Maybe there have been
misunderstandings caused by wrong expectations caused by a lack of
documentation. I also fail to see how git submodules could make things
any better. Imho using git submodules, especially for meta-stuff is
a very bad practise, many distributions decided against that and for
good reason, see e.g. some input from puppetlinux [1]. Money quote:
"All of this smells of an antipattern. Git submodules sound great
initially, but the farther down this road that you go, the more work
you're going to generate trying to work around the limitations of git
submodules."
Maybe subtrees can be better. Having an explicite manifest, like
feeds.conf in the SDK, does the trick. I agree that it's a bit
hidden and that practise has not been very well documented (yet).

Anyway. Back to the real issue here:
Imho you shouldn't use the SDK to build core packages or even any
package provided in a binary feed belonging to that release and then
use that version (which you have just built locally) in the
ImageBuilder. Yes, you may need to build it in order to build your
local packages to satisfy build dependencies. But when it comes to use
the ImageBuilder, always use the upstream binary feeds and only include
your hand full of local packages in a seperate feed.
If you really need to modify packages already included in an upstream
binary feed, rename them and use the (now working) PROVIDES variable to
satisfy dependencies (or make sure your modifications go upstream!!!)


Cheers


Daniel


[1]: http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/

> 
> James
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev