Age | Commit message (Collapse) | Author |
|
If we have installed some lib32 package which depends on perl/bash,
then populating sdk for that image would fail with the following error.
Error:
Problem: package lib32-libxml-namespacesupport-perl-1.12-r0.corei7_32 requires lib32-perl, but none of the providers can be installed
package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target conflicts with /usr/bin/perl provided by lib32-perl-5.30.0-r0.corei7_32
package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target conflicts with libperl.so.5 provided by lib32-perl-5.30.0-r0.corei7_32
This could be produced by the following steps:
1. IMAGE_INSTALL_append = " lib32-valgrind"
2. bitbake core-image-minimal -c populate_sdk
We need to extend all packages in DUMMYPROVIDES to avoid such problems.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
With postgresql added to IMAGE_INSTALL, we will get the following
error when building for 64bit BSPs.
Problem: package postgresql-11.3-r0.corei7_64 requires libperl.so.5()(64bit), but none of the providers can be installed
A previous patch has added libperl.so.5 to DUMMY_PROVIDES, but this
is not enough. Because for 64bit BSP, it should also provide libperl.so.5()(64bit).
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add libperl.so.5 to DUMMY_PROVIDES to avoid do_rootfs failure like
below.
Error:
Problem: package postgresql-11.3-r0.core2_32 requires libperl.so.5, but none of the providers can be installed
package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target conflicts with perl provided by perl-5.30.0-r0.core2_32
package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target conflicts with perl-module-strict provided by perl-5.30.0-r0.core2_32
This problem could be reproduced by add 'postgresql' to IMAGE_INSTALL
and then `bitbake core-image-minimal -c populate_sdk'.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It exists a situation that there is a common config file includes
multilib.conf but variable MULTILIBS is not set by default:
require conf/multilib.conf
MULTILIBS ?= ""
When build target-sdk-provides-dummy in a build project, it fails with
following steps:
1 $ echo 'MACHINE = "qemux86"' >>conf/local.conf
$ bitbake target-sdk-provides-dummy
2 $ cat <<EOF >>conf/local.conf
MACHINE = "qemux86-64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "i586"
EOF
$ bitbake target-sdk-provides-dummy
$ bitbake lib32-target-sdk-provides-dummy
It fails to build lib32-target-sdk-provides-dummy with error messages:
| ERROR: target-sdk-provides-dummy-1.0-r0 do_packagedata: The recipe target-sdk-provides-dummy
| is trying to install files into a shared area when those files already exist. Those files
| and their manifest location are:
| .../tmp/pkgdata/qemux86-64/lib32-target-sdk-provides-dummy
| (matched in manifest-qemux86_64-lib32-target-sdk-provides-dummy.packagedata)
| .../tmp/pkgdata/qemux86-64/runtime/lib32-target-sdk-provides-dummy
| (matched in manifest-qemux86_64-lib32-target-sdk-provides-dummy.packagedata)
| ... snip ...
| Please verify which recipe should provide the above files.
Add related directories to SSTATE_DUPWHITELIST to avoid the failures.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Vincent Prince <vincent.prince.fr@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This avoids errors when running populate_sdk under opkg:
* Problem 1/1:
* - package busybox-dev-1.30.1-r0.core2-64 requires busybox = 1.30.1-r0, but none of the providers can be installed
*
* Solution 1:
* - allow deinstallation of target-sdk-provides-dummy-1.0-r0.sdk-provides-dummy-target
* Solution 2:
* - do not ask to install a package providing busybox-dev
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When 'adduser' package, which is from meta-perl layer, is added to rootfs,
we will get do_populate_sdk failure like below.
Error:
Problem: package perl-module-cwd-5.24.4-r0.core2_64 requires perl-module-dynaloader, but none of the providers can be installed
- package perl-module-file-temp-5.24.4-r0.core2_64 requires perl-module-cwd, but none of the providers can be installed
- package perl-module-dynaloader-5.24.4-r0.core2_64 requires perl-module-config, but none of the providers can be installed
- package adduser-3.118-r0.core2_64 requires perl-module-file-temp, but none of the providers can be installed
- package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target conflicts with perl provided by perl-5.24.4-r0.core2_64
This is because adduser depends on some perl modules which are not
listed in target-sdk-provides-dummy.
So add these perl modules to avoid such failure.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
opkg needs the replaces/conflicts/provides in order for this package
to function as intended. When enabled, this code caused failures for
core-image-sato -c populate_sdk.
The reason is that nativesdk-autoconf has several perl dependencies. We
need to list more of the things which this package provides/conflicts
with in order for it to function correctly. Therefore add the missing
entries.
(From OE-Core rev: 27412b377dda47daa87bfcb3a41babe53ff8b0a3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When we migrated rpm v5 -> v4, we lost the ability to drop "per file"
dependencies from the rpm backend for things like "/bin/bash" and
"/usr/bin/env" which meant the sdks were becomming 'bloated'.
This restores the functionality using a dummy package, similarly to
the way the buildtools perl issue was addressed. It also removes
the non-functional old code so as not to confuse people in future.
I ran into this problem trying to filter dependencies to only rpms
a build directly depends upon and it turns out we have some determinism issues
in this area so this is something key to fix.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|