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

[Pau]

Hi Daniel, thanks for your reply. Find my comments in-line.

On 28/03/17 22:37, Daniel Golle wrote:
> Hi Pau,
> 
> On Tue, Mar 28, 2017 at 09:28:22PM +0200, Pau wrote:
>> Hi.
>>
>> I am using the SDK and IB from LEDE 17.01.0 release (mips_24kc). I've
>> been using it successfully the last days until now. I did not change
>> anything but I get the error:
>>
>> * opkg_install_pkg: Package luci-lib-nixio sha256sum mismatch. Either
>> the opkg or the package index are corrupt. Try 'opkg update'.
>>
>> Then I went to downloads.lede-project.org [1] and I see that there are
>> new compiled packages with date "Tue Mar 28 18:35:15 2017".
>> Luci-lib-nixio is one of them [2] (which now is published on the
>> repository with a new version).
> 
> Packages from the feeds and even base-packages (think: openssl) can
> change after a release, just like for other distributions.
> The error message you see more looks like being caused by inconsistent
> Package index not matching the actual binaries. Maybe regenerating
> the index can fix that...?

I know I can manually fix it. But let me explain my corner case:

The current SDK is compiling luci-lib-nixio which I want to include to
the firmware generated by the ImageBuilder (I want to include my local
version, not the repository one).

The source of this package comes from the SDK's feeds.conf.default which
points to commit "a100738163585ae1edc24d832ca9bef1f34beef0".

As the current LEDE official repository for 17.01.0 has been updated the
luci-lib-nixio package has a newer version. In consequence the
ImageBuilder selects it instead of my local compiled package.

So it is an unexpected behavior, and it makes impossible for us to be
sure that our LibreMesh SDK will work, not even when sticking to a LEDE
release.

In this case luci.lib-nixio is not a critical package and we can use the
vanilla one, but the same might happen with any other package that we
are compiling with different options and we expect the IB to use it
instead of the online one.

>>
>> In the other hand the feeds.conf.default file included in the release
>> SDK points to the specific commit
>> a100738163585ae1edc24d832ca9bef1f34beef0 from  Sat Jan 28 01:38:06 2017.
>> The SDK published then is not consistent with the current package binary
>> repositories.
> 
> The SDK doesn't need to be consistent with all packages, but the fixed
> commit (instead of a branch) is indeed misleading (and most likely got
> rather political reasons, like not poluting a repo called
> github.com/openwrt/packages with a branch called for-lede-17.01...)
> 
>>
>> So my question here is: what's the point for publishing a Release if the
>> packages included are changing? Is this the expected behavior?
> 
> Definitely not the expected behaviour, but packages may and should
> change, eg. for bug or security fixes.

IMHO and as far I understand the concept of Release, if there are fixes
a new revision must be published instead of modifying the current one
(i.e 17.01.1). Once a release is published it is expected to be always
the same.

> 
> Cheers
> 
> 
> Daniel
> 
>>
>> Thanks.
>>
>> [1]
>> https://downloads.lede-project.org/releases/17.01.0/packages/mipsel_24kc/
>> [2]
>> https://downloads.lede-project.org/releases/17.01.0/packages/mips_24kc/luci/luci-lib-nixio_git-17.073.42825-b47a21f-1_mips_24kc.ipk
>>
>> -- 
>> ./p4u
>>
> 
> 
> 
> 
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

-- 
./p4u

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20170328/ecd3e41a/attachment.sig>