[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