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

[Alberto Bursi]

On 03/29/2017 06:08 AM, James Feeney wrote:
> Realize?  No - I'm still learning how this build process works in LEDE.  My
> impression is that you are distinguishing between "packages" and some other type
> of thing, which the lede-project.org site seems to implicitly, and generically,
> refer to as just "firmware" - even though a "package" is also a type of
> "firmware", and this "firmware" is also a type of "package".  I will infer that
> you mean to distinguish between the "kernel and base filesystem" package from
> all other "packages".

LEDE is using the standard term for "package" in linux world, where a 
"package" is an archive containing a program or some scripts and its 
accompanying configuration and information used to integrate it in the 
system, installed by a package manager (opkg in this case), and the 
whole system is made of such packages assembled together around a Linux 
kernel.

Each package is compiled on its own and then when it's all done the 
packages are "installed" in a temporary root that will then be 
compressed to become the squashfs root in the device firmware.

Also the kernel is handled like a package for the build system, but 
since most devices expect it outside of root filesystem in various ways, 
it's added to the firmware image the way the device's bootloader expects it.


This is all pretty standard for any other Linux distro, Ubuntu, Debian, 
OpenSUSE, RHEL, whatever.

> You also seem to be implying that all the various "kernel and base filesystem"
> package builds are now precisely repeatable - even though this fact does not
> seem to be documented anywhere.

If you look at a random package makefile (the file defining settings for 
building a specific package)
https://github.com/lede-project/source/blob/master/package/utils/adb/Makefile

You will notice that it states the official download link for the 
sources, a SHA256 hash and a specific version for the package name.
On some other packages it will state git commit or other way to identify 
the same source to pull down and build.
They generally favor tarballs, archives with sources from official 
releases, but some upstream projects don't always have that.

In /patches folder of each package's folder you will find any patches 
that will be applied to the source after downloading it, before 
compiling, again the example package:
https://github.com/lede-project/source/blob/master/package/utils/adb/patches/001-create_Makefile.patch
There are also other folders for configuration files or for uci 
integration for each package that needs it (the example package does not).

The kernel's makefile is a bit more complex because of reasons, but you 
can see that it still uses the same structure,
pulling down the same kernel version (depending from device) every time.

https://github.com/lede-project/source/blob/master/package/kernel/linux/Makefile

Then all this stuff is compiled by LEDE's own toolchain, which is again 
handled like packages (see /toolchain and /tools) so you will always 
have the same compiler/tools as everyone else as they get downloaded 
from the same sources and at the same version.

When you run a "make" the LEDE build system will use your system's 
existing building infrastructure to compile the LEDE's toolchain first, 
and then use that to compile the packages. This also has the major 
benefit of not requiring the user to set up a cross-compiling toolchain 
that is rather annoying and relatively complex.

Is this enough for having repeatable builds?
I'm more like a long-time user so I don't know what "repeatable builds" 
mean beyond what I read from the internet, it seems this is more or less it.

>
> With respect to the lingo, "package feeds" and "project making the release", I
> have no understanding of the meaning of that statement.  Perhaps you could
> define precisely "package feeds" and "project making the release"?

Just as OpenWRT, there is a main project where the packages are 
maintained directly from core developers, and "package feeds" that are 
source repositories that contain additional packages, maintained by 
community (each package has its own maintainer).
This is LEDE's main repo (on github) https://github.com/lede-project/source

These are official package feeds (currently shared with OpenWRT):
https://github.com/openwrt/luci
https://github.com/openwrt/telephony
https://github.com/openwrt-routing/packages

Being "official feeds", the stuff from there will get compiled and 
offered in official download server, but it's not technically LEDE or 
OpenWRT proper, it's community-maintained.
The "package feed" system is designed to allow easy addition of your own 
custom feeds too in your custom firmware images, but you will have to 
compile them and host them on your own servers, of course.

If you look at the built packages here, 
https://downloads.lede-project.org/releases/17.01.0/packages/x86_64/

You find that they are divided by feed name.
Packages in "base" come from main repo, and also from main repo you get 
packages that are found in target-specific folders, like for example 
here 
https://downloads.lede-project.org/releases/17.01.0/targets/x86/64/packages/ 
that you see has mostly kmod-* and other drivers.

>
> Simply a combination of my uninformed state of mind, where I am left to "fill in
> the blanks" with the information presented in the past, specifically that "you
> don't really have a repeatable build."  Since that seems to have changed, it
> would be good to advertise that fact in public, which is to say, to document
> that fact on the lede-project.org website.

Yeah, I agree that adding this to the wiki would be good.
If you confirm that this answers your questions (more or less), I'm 
adding it to the wiki.


-Alberto