<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 18, 2016 at 7:19 PM Christopher Larson <<a href="mailto:clarson@kergoth.com">clarson@kergoth.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Apr 18, 2016 at 6:38 PM Paul Eggleton <<a href="mailto:paul.eggleton@linux.intel.com" target="_blank">paul.eggleton@linux.intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 18 Apr 2016 21:01:27 Denys Dmytriyenko wrote:<br>
> On Tue, Apr 19, 2016 at 10:35:29AM +1200, Paul Eggleton wrote:<br>
> > Hi Denys,<br>
> > On Mon, 18 Apr 2016 18:14:55 Denys Dmytriyenko wrote:<br>
> > > I'm still using the old-style SDK (meta-toolchain) for our products due<br>
> > > to some code customizations in it and some of our use cases rely on the<br>
> > > opkg package management database being present in sysroots, so packages<br>
> > > can be manipulated in SDK with opkg command. It appears that<br>
> > > /var/lib/opkg is now empty and the package database is no longer<br>
> > > supplied with the SDK.<br>
> > ><br>
> > > I know about the new-style populate_sdk and the even newer Extensible<br>
> > > SDK, but not yet ready to convert our old use cases to that. Since there<br>
> > > were lots of changes around the way SDKs work in OE-Core in the past<br>
> > > couple releases, I'm failing to find the change that causes opkg DB to<br>
> > > be missing from the old style SDK. I'll appreciate any pointers in<br>
> > > helping me debug and/or fix this issue with my SDKs. Thanks.<br>
> ><br>
> > As far as ipk is concerned I think it was this commit:<br>
> > <a href="http://cgit.openembedded.org/openembedded-core/commit/?id=c8e0ec2da9ad4c" rel="noreferrer" target="_blank">http://cgit.openembedded.org/openembedded-core/commit/?id=c8e0ec2da9ad4c</a><br>
> > e1c103966906a85f68c15400dd><br>
> > Unfortunately it wasn't made optional.<br>
><br>
> Thanks, Paul!<br>
><br>
> Unfortunately, the change is in the library, which is quite difficult to<br>
> override in another layer...<br></blockquote><div><br></div><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Actually, overriding a library is trivial given the way we do our python package. Copy meta/lib/oe/__init__.py into <your layer>/lib/oe/, copy meta/lib/oe/sdk.py to <your layer>/lib/oe/ and modify, and make sure your layer is prioritized correctly, and your forked version will be used in preference.</div><div><br></div><div>It's not ideal, for the same reasons it's not ideal to override a class -- you're stuck keeping it in sync, so for that reason I'd not recommend it, but it's not difficult to do the override :)</div></div></div></blockquote><div><br></div><div>Just as an FYI, we've done this on many occasions in meta-mentor-staging as a temporary measure while waiting for the fix to propagate to upstream. It's handy for cases like that, where the lifetime is limited. </div></div></div>