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

Gui Iribarren gui at altermundi.net
Tue Mar 28 15:19:02 PDT 2017


On 28/03/17 17: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.

i agree packages can and should be maintained, but in progressive releases.

i.e. if i install ubuntu 12.04 today, i expect to have exactly the same
system than what i got if i installed ubuntu 12.04 at the time of its
release

if i want to get the fixes that happened after the time of original
12.04 release, i'd install 12.04.1

or, install 12.04 and run "apt-get update && apt-get upgrade"

the equivalent in lede would be ..."opkg update && opkg upgrade *"?
but it doesn't even really make sense, given squashfs and so on.

so i'm thinking out loud: wouldn't it make sense to leave the packages
tree "frozen" at the time of release?
and any updated packages compiled and dumped to a different feed, like
17.01-updates ?
https://downloads.lede-project.org/releases/17.01-updates/packages/

i thought debian did something like this, but i just checked and the
"jessie" dist *does* change over time (5 minutes ago i thought only
"jessie-updates" changed)

i must admit that after some thinking, i'm utterly confused, so will
probably accept whatever reasoning anyone provides,
all we want to do is create a firmware based on a specific LEDE release,
and not fear that if we want to rebuild the exact same firmware in two
months (or days!), we will get a different (broken) result :)

> 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...?
> 
>>
>> 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.
> 
> 
> 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
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 



More information about the Lede-dev mailing list