[OE-core] [PATCH 1/1] nativesdk/sdk: Fix sdk dummy providers for opkg

[Andrej Valek]

Hello Richie,

We have made some deeper analysis of this problem.

In our opinion the code as it is now does not work for any packaging method.
For RPM it's a silent failure (purpose of dummy class is to replace
tools like perl, however without RCONFLICTS clause those tools will be
installed instead anyway of replaced.
OPKG correctly creates a hard failure when RCONFLICTS is not set.

The problem in RPM/DNF is that it cannot compare conflict between
package name and file name (e.g. perl vs. /usr/bin/perl), so it will try
install both.
For this you have implemented a "workaround" by removing the RCONFLICTS
which however makes the package useless for RPM and breaking OPKG build.

We ha tried to replace /usr/bin/perl by perl (which works fine), however
there is still /bin/sh and /bin/env which can have multiple providers
and we can't conflict with any possible package out there.

Unfortunately reworking RPM/DNS is something we don't know how to.
Therefore we would like to at least fix OPKG that it does not crash
during build and leave the background problem for later (e.g. create
bugreport).

Would you reconsider merging this MR or would you accept if we create
separate recipe for OPKG?


Regards,
Andrej & Peter

On 11/20/18 1:53 PM, richard.purdie at linuxfoundation.org wrote:
> On Tue, 2018-11-20 at 12:17 +0100, Andrej Valek wrote:
>>> ERROR:  OE-core's config sanity checker detected a potential
>>> misconfiguration.
>>>     Either fix the cause of this error or at your own risk disable
>>> the checker (see sanity.conf).
>>>     Following is the list of potential problems / advisories:
>>>
>>>     Required perl module(s) not found: Text::ParseWords
>>> Thread::Queue
>>> Data::Dumper
>>
>> It means that perl wasn't excluded from buildtools-tarball.
>>
>> Signed-off-by: Andrej Valek <andrej.valek at siemens.com>
>> ---
>>  meta/recipes-core/meta/dummy-sdk-package.inc | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-core/meta/dummy-sdk-package.inc
>> b/meta/recipes-core/meta/dummy-sdk-package.inc
>> index eafcb823ab..44fb1cb714 100644
>> --- a/meta/recipes-core/meta/dummy-sdk-package.inc
>> +++ b/meta/recipes-core/meta/dummy-sdk-package.inc
>> @@ -20,7 +20,11 @@ PR[vardeps] += "DUMMYPROVIDES"
>>  python populate_packages_prepend() {
>>      p = d.getVar("PN")
>>      d.appendVar("RPROVIDES_%s" % p, "${DUMMYPROVIDES}")
>> -    #d.appendVar("RCONFLICTS_%s" % p, "${DUMMYPROVIDES}")
>> -    #d.appendVar("RREPLACES_%s" % p, "${DUMMYPROVIDES}")
>> +
>> +    # opkg needs some additional package dependencies handling
>> +    pkg_type = d.getVar("IMAGE_PKGTYPE")
>> +    if pkg_type == "ipk":
>> +        d.appendVar("RCONFLICTS_%s" % p, "${DUMMYPROVIDES}")
>> +        d.appendVar("RREPLACES_%s" % p, "${DUMMYPROVIDES}")
>>  }
> 
> Sadly we can't do this, both do_package_write_ipk and
> do_package_write_rpm depend on do_package and this would cause
> do_package to change depending on the package backend selected which
> would mean inconsistently generated packages. We're going to have to
> find a better solution (and maybe add do_populate_sdk testing to the
> nightly-packagemanagers test to ensure that doesn't regress).
> 
> Cheers,
> 
> Richard
> 
>