Re: [OE-core] [PATCH 1/1] nativesdk/sdk: Fix sdk dummy providers for opkg
Sorry I apologize to give you this naming. I didn't want to offend you. Would be great, if you can create a official commit for it. Thank you, Andrej On 12/6/18 12:20 PM, richard.pur...@linuxfoundation.org wrote: > On Thu, 2018-12-06 at 12:15 +0100, Andrej Valek wrote: >> Hello Richie, > > Who is Richie? > >> Thank you for our work. We have verified it and it's working on both >> package systems (ipk and rpm). But we're not sure about the deb >> packages. >> >> Maybe a question about the "nativesdk-sdk-provides-dummy" change. Why >> didn't you put them into "nativesdk-buildtools-perl-dummy" ? There >> are similar packages like you have added. Could you please explain >> it? > > The buildtools tarball doesn't depend on the things I added to the sdk- > provides so didn't need them. Adding them wouldn't hurt but it wasn't > where we were seeing the failures, or how to fix them. > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] nativesdk/sdk: Fix sdk dummy providers for opkg
Hello Richie,
Thank you for our work. We have verified it and it's working on both
package systems (ipk and rpm). But we're not sure about the deb packages.
Maybe a question about the "nativesdk-sdk-provides-dummy" change. Why
didn't you put them into "nativesdk-buildtools-perl-dummy" ? There are
similar packages like you have added. Could you please explain it?
Regards
Andrej & Peter
On 12/5/18 6:38 PM, richard.pur...@linuxfoundation.org wrote:
> On Wed, 2018-12-05 at 08:59 +0100, Andrej Valek wrote:
>> 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.
>
> That isn't true as for the buildtools-tarball case it *is* working with
> rpm.
>
>> 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
>
> If I merge your patch, the autobuilder breaks and shows errors. Is that
> acceptable?
>
>> or would you accept if we create separate recipe for OPKG?
>
> No, that is hacking around the problem.
>
> I took a look at this myself. It seems that the patch below does work
> for rpm. That does make me wonder about some of things you've mentioned
> above. Basically the problem is that some recipes like nativesdk-
> autoconf depend on more than just /usr/bin/perl. We therefore need to
> extend the providers list to cover the various possibilities.
>
> Cheers,
>
> Richard
>
>
> diff --git a/meta/recipes-core/meta/dummy-sdk-package.inc
> b/meta/recipes-core/meta/dummy-sdk-package.inc
> index eafcb823ab..4d653706b1 100644
> --- a/meta/recipes-core/meta/dummy-sdk-package.inc
> +++ b/meta/recipes-core/meta/dummy-sdk-package.inc
> @@ -20,7 +20,7 @@ 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}")
> +d.appendVar("RCONFLICTS_%s" % p, "${DUMMYPROVIDES}")
> +d.appendVar("RREPLACES_%s" % p, "${DUMMYPROVIDES}")
> }
>
> diff --git a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb
> b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb
> index 11a727d486..d33e978666 100644
> --- a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb
> +++ b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb
> @@ -2,6 +2,26 @@ DUMMYARCH = "sdk-provides-dummy-${SDKPKGSUFFIX}"
>
> # Add /bin/sh?
> DUMMYPROVIDES = "\
> +nativesdk-perl \
> +nativesdk-libxml-parser-perl \
> +nativesdk-perl-module-bytes \
> +nativesdk-perl-module-carp \
> +nativesdk-perl-module-constant \
> +nativesdk-perl-module-data-dumper \
> +nativesdk-perl-module-errno \
> +nativesdk-perl-module-exporter \
> +nativesdk-perl-module-file-basename \
> +nativesdk-perl-module-file-compare \
> +nativesdk-perl-module-file-copy \
> +nativesdk-perl-module-file-find \
> +nativesdk-perl-module-file-glob \
> +nativesdk-perl-module-file-path \
> +nativesdk-perl-module-file-stat \
> +nativesdk-perl-module-getopt-long \
> +nativesdk-perl-module-io-file \
> +nativesdk-perl-module-posix \
> +nativesdk-perl-module-thread-queue \
> +nativesdk-perl-module-threads \
> /bin/bash \
> /usr/bin/env \
> /usr/bin/perl \
> diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> index 714d15d8ba..57c10044f8 100644
> --- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> +++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> @@ -1,6 +1,9 @@
> DUMMYARCH = "sdk-provides-dummy-target"
>
> DUMMYPROVIDES = "\
> +busybox \
> +bash \
> +perl \
> /bin/sh \
> /bin/bash \
> /usr/bin/env \
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] nativesdk/sdk: Fix sdk dummy providers for opkg
On Wed, 2018-12-05 at 08:59 +0100, Andrej Valek wrote:
> 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.
That isn't true as for the buildtools-tarball case it *is* working with
rpm.
> 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
If I merge your patch, the autobuilder breaks and shows errors. Is that
acceptable?
> or would you accept if we create separate recipe for OPKG?
No, that is hacking around the problem.
I took a look at this myself. It seems that the patch below does work
for rpm. That does make me wonder about some of things you've mentioned
above. Basically the problem is that some recipes like nativesdk-
autoconf depend on more than just /usr/bin/perl. We therefore need to
extend the providers list to cover the various possibilities.
Cheers,
Richard
diff --git a/meta/recipes-core/meta/dummy-sdk-package.inc
b/meta/recipes-core/meta/dummy-sdk-package.inc
index eafcb823ab..4d653706b1 100644
--- a/meta/recipes-core/meta/dummy-sdk-package.inc
+++ b/meta/recipes-core/meta/dummy-sdk-package.inc
@@ -20,7 +20,7 @@ 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}")
+d.appendVar("RCONFLICTS_%s" % p, "${DUMMYPROVIDES}")
+d.appendVar("RREPLACES_%s" % p, "${DUMMYPROVIDES}")
}
diff --git a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb
b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb
index 11a727d486..d33e978666 100644
--- a/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb
+++ b/meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb
@@ -2,6 +2,26 @@ DUMMYARCH = "sdk-provides-dummy-${SDKPKGSUFFIX}"
# Add /bin/sh?
DUMMYPROVIDES = "\
+nativesdk-perl \
+nativesdk-libxml-parser-perl \
+nativesdk-perl-module-bytes \
+nativesdk-perl-module-carp \
+nativesdk-perl-module-constant \
+nativesdk-perl-module-data-dumper \
+nativesdk-perl-module-errno \
+nativesdk-perl-module-exporter \
+nativesdk-perl-module-file-basename \
+nativesdk-perl-module-file-compare \
+nativesdk-perl-module-file-copy \
+nativesdk-perl-module-file-find \
+nativesdk-perl-module-file-glob \
+nativesdk-perl-module-file-path \
+nativesdk-perl-module-file-stat \
+nativesdk-perl-module-getopt-long \
+nativesdk-perl-module-io-file \
+nativesdk-perl-module-posix \
+nativesdk-perl-module-thread-queue \
+nativesdk-perl-module-threads \
/bin/bash \
/usr/bin/env \
/usr/bin/perl \
diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
index 714d15d8ba..57c10044f8 100644
--- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
+++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
@@ -1,6 +1,9 @@
DUMMYARCH = "sdk-provides-dummy-target"
DUMMYPROVIDES = "\
+busybox \
+bash \
+perl \
/bin/sh \
/bin/bash \
/usr/bin/env \
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] nativesdk/sdk: Fix sdk dummy providers for opkg
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.pur...@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
>> ---
>> 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
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] nativesdk/sdk: Fix sdk dummy providers for opkg
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
> ---
> 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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
