On 30.04.2019 12:26, Richard Purdie wrote:
>
> Merging a QA test which causes hundreds of warnings isn't really going
> to help unless we have a strategy for fixing it.
I agree merging this only makes sense if we commit to fixing the issue.
In my opinion the strategy for fixing it would be to always split packages that
consists of both binaries and libs into two.
This is already done for many like sqlite3 (sqlite3 vs libsqlite3). This check
would just ensure that this rule is always followed.
This would make it easier to separate the two. Let's take the example that you
have two applications A (32bit) and B (64bit) both using sqlite3.
In this case the two would link to lib32-libsqlite3 and libsqlite3.
If the package contained both the library and the binary you would end up with
both libs but one of the two binaries (not sure this is deterministic).
If the packages are only lib and only binary then you would explicitly need to
select either the 32bit or the 64bit variant.
In practice this would not only benefit the multilib case. It would also help
with avoiding unnecessarily installed binaries just because somebody is using a
library
bundled in the same package.
>
> As I understand it, if you install python 32bit and 64 bit, you should
> get the libraries from both but only the binaries from the one that
> wins. That should mean anything linking to the lib should work?
>
> What am I missing? Is something not working like that? Is this with the
> rpm or opkg implementation? (they're very different)
I think the issue with scripting languages (especially python) is different
from the general case above (sqlite3).
And maybe the insane check in the current form is not covering all cases.
Pascal
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
