World builds also enable apt and dpkg, but there is no problem with that for you? There is no consistency here; if you want to start excluding things from world based on what packaging is enabled, you need to treat all options equally, including deb and ipk.
The original problem was that libsolv pulls in the full set of rpm executables and libraries, which erroneously triggers the rpm test on target. We can solve this by making libsolv pull in only the rpm libraries and not executables, so that rpm test will be skipped. Or maybe even make the test itself check whether rpm is the packaging format and skip otherwise.
Alex
On Wed, Feb 12, 2020 at 8:49 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> But you do not need to fix or touch dnf at all. You only need to adjust rpm packaging and split it in two parts instead of bundling everything into a single package.
>
when we do world builds without package_rpm, dnf and related packages
get compiled which is unnecessary and moreover wrong and when we mark
libsolv to enable rpmdb only for package_rpm, this becomes even more evident.
Perhaps, I am missing what you intend to convey, in that case maybe you can send
code changes to support what you are intending here.
> Alex
>
> On Wed 12. Feb 2020 at 23.16, Khem Raj <raj.khem@gmail.com> wrote:
>>
>> On Wed, Feb 12, 2020 at 2:00 PM Alexander Kanavin
>> <alex.kanavin@gmail.com> wrote:
>> >
>> > I would still prefer to just split rpm packaging into binaries and libraries, and avoid the need to blacklist and tweak recipes based on what PACKAGE_CLASSES is set to altogether. That setting should not leak into recipes, and should only matter from do_package onwards. Can you look into the rpm recipe please?
>> >
>>
>> dnf and dnf related packages expecting rpmdb support in libresolv. I
>> do not know dnf well enough to fix it and moreover it has no direct
>> use for my usecase either. I also don't see a point of entertaining
>> dnf for non-rpm backends. Its not intended for that either even if we
>> were to make dnf not want rpmdb what good will it do to build for
>> distros who do not use rpm. These changes do not change poky defaults
>> which use rpm as default. OE-core does not and I dont know of any
>> opkg user who also has rpmdb needed.
>>
>> > Alex
>> >
>> > On Wed, 12 Feb 2020 at 20:19, Khem Raj <raj.khem@gmail.com> wrote:
>> >>
>> >> dnf does not work with opkg or dpkg/apt anyway
>> >>
>> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> >> ---
>> >> v2: Use PNBLACKLIST instead of anon python
>> >>
>> >> meta/recipes-devtools/dnf/dnf_4.2.2.bb | 2 ++
>> >> meta/recipes-devtools/libdnf/libdnf_0.28.1.bb | 1 +
>> >> 2 files changed, 3 insertions(+)
>> >>
>> >> diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
>> >> index f38167f1ad..220f1aabbd 100644
>> >> --- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
>> >> +++ b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
>> >> @@ -84,3 +84,5 @@ SYSTEMD_SERVICE_${PN} = "dnf-makecache.service dnf-makecache.timer \
>> >> dnf-automatic-notifyonly.service dnf-automatic-notifyonly.timer \
>> >> "
>> >> SYSTEMD_AUTO_ENABLE ?= "disable"
>> >> +
>> >> +PNBLACKLIST[dnf] ?= "${@bb.utils.contains('PACKAGE_CLASSES', 'package_rpm', '', 'does not build correctly without package_rpm in PACKAGE_CLASSES', d)}"
>> >> diff --git a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
>> >> index 882c435b32..49afa04812 100644
>> >> --- a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
>> >> +++ b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
>> >> @@ -26,4 +26,5 @@ EXTRA_OECMAKE_append_class-native = " -DWITH_GIR=OFF"
>> >> EXTRA_OECMAKE_append_class-nativesdk = " -DWITH_GIR=OFF"
>> >>
>> >> BBCLASSEXTEND = "native nativesdk"
>> >> +PNBLACKLIST[libdnf] ?= "${@bb.utils.contains('PACKAGE_CLASSES', 'package_rpm', '', 'does not build correctly without package_rpm in PACKAGE_CLASSES', d)}"
>> >>
>> >> --
>> >> 2.25.0
>> >>
>> >> --
>> >> _______________________________________________
>> >> Openembedded-core mailing list
>> >> Openembedded-core@lists.openembedded.org
>> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core