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

Daniel Golle daniel at makrotopia.org
Tue Mar 28 17:45:00 PDT 2017


On Tue, Mar 28, 2017 at 10:55:09PM +0200, Pau wrote:
> 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).

Ok, now I understand better. So the package index of the binary feed
is consistent.

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

I get that problem, and it can be solved easily by removing the git
commit hash from feeds.conf in the SDK and rather use the current
snapshot instead.
I agree that the lack of a lede-17.01 release branch on the package
feeds may cause weird and problematic situations, especially in the
future once LEDE HEAD has diverged more from 17.01.x released versions.

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

I fail to see the drama, why would that truely prevent you from doing
anything? What is the behaviour you'd expect?

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

Ok, all this is expected behaviour and shouldn't prevent anyone from
building their packages using the SDK and then including their binaries
in the ImageBuilder.

Simply speaking, if you modify (ie. fork) a package you should either
rename it or pull-request your changes upstream.


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

Why is that? And when has it ever been like that?
Binary packages have also been updated for past OpenWrt releases,
especially but not exclusively to fix security issues. (e.g. HeartBleed
was fixed in binary packages all the way back to 12.09 afaik)


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




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