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

[James Feeney]

Hi Alberto

> 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.

I haven't seen a preferred term for the class of this combined kernel and base
filesystem.  LEDE does name each of them individually, based upon the target
architecture.  It would be nice to have some generally recognized single name
for this class, "the kernel-fs packages" or some such.

Of course it's a little complicated, since most traditional Linux distros target
only one or two hardware architectures, and LEDE targets many many different
target architectures.  But then, that's the whole point of LEDE.

> 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.
> ...

So, if I understand, there always exists a set of hashes to verify that, at any
time in the future, a package can be built which is identical to any package
built in the past.

Bastian also mentions "checkout LEDE and all feeds at a specific timestamp" as
an approach.  This suggest two general tracking mechanisms: 1) tracking by hash,
and 2) tracking by time-stamp.  Is one of these mechanisms, or are both of these
mechanisms, used universally in the LEDE package management system?

> 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:
> ...

Hmm - it is not entirely clear to me that, if the patch set changes in the
future, the version number of the package will be distinctly incremented, as
would be pretty standard for any other Linux distro.  Does each package have a
minor version number, in the source and binary repositories, to allow
distinguishing patch set changes, used in each build of every package?

> Is this enough for having repeatable builds?

Perhaps, assuming that these distinct version numbers exist, and that these
historic time-stamp or hash verified sources are archived somewhere and available.

> 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.

It sounds like the LEDE package management system has changed and improved over
the past months.  It would be great to see your description of the LEDE package
management system and build system on the wiki!

Still, as Daniel has suggested, I may not quite understand Pau's underlying
concern, which started this thread.  Looking back, Pau says:
"The SDK published then is not consistent with the current package binary
repositories", and "... if there are fixes a new revision must be published
instead of modifying the current one (i.e 17.01.1).

Are these concerns simply misunderstandings of the changing LEDE package
management system?  Or, are these concerns addressing actual shortcomings with
version control in the LEDE package management system?  I don't think I've heard
a definite answer.  I was not trying to hijack Pau's thread, but Daniel has
questioned whether my issues and Pau's issues are the same, or not.

Thanks
James