[OE-core] [PATCH] libmodulemd: fix erroneous linking against v2 library when v1 was requested

[Alexander Kanavin]

I'm not sure that would work, as at do_rootfs time both createrepo_c
(v2 user) and libdnf (v1 user) need to be present in the
sysroot-native, and so v1 and v2 files would clash at that point
(libmodulemd.so would be provided by both).

I am kind of hoping that libdnf would migrate off v1 to v2, and we
could then simply disable v1 altogether. So far it hasn't happened,
and libdnf update is now also blocked by the c++ code that older
compilers don't like, so I'd leave thing as they are for now.

Alex

On Wed, 22 May 2019 at 13:08, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
>
> On Wed, 2019-05-22 at 12:28 +0200, Alexander Kanavin wrote:
> > On Wed, 22 May 2019 at 04:04, Khem Raj <raj.khem at gmail.com> wrote:
> > > > +
> > > > + pkg.generate(
> > > > +-    libraries : modulemd_v1_lib,
> > > > ++    libraries : '-l:libmodulemd.so.1',
> > >
> > > shouldn't it be generating a separate package for v1 ?
> > > hardcoding linker paths seems a bit hackish here, is it going
> > > to generate a .pc file with .so.1 version ?
> >
> > The problem is that both v2 and v1 are installed into the sysroot; we
> > don't have a mechanism to choose one or the other via DEPENDS (unlike
> > desktop distros where you can install -v1-dev or -v2-dev package for
> > your build).
> > Then both v2 and v1 .pc files (without this patch) refer to
> > '-lmodulemd' which in our case always resolves to v2 library.
> >
> > Wth the patch the generated v1 .pc will look like this, while v2
> > continues to use the original '-lmodlulemd' in Libs:
> >
> > prefix=${pcfiledir}/../../../usr
> > libdir=${prefix}/lib
> > includedir=${prefix}/include
> >
> > Name: modulemd
> > Description: Module metadata manipulation library
> > Version: 1.8.10
> > Requires: glib-2.0, gobject-2.0
> > Libs: -l:libmodulemd.so.1
> > Cflags: -I${includedir}/modulemd
>
> FWIW I think if there were two different recipes we could select which
> was in the sysroot through DEPENDS?
>
> Cheers,
>
> Richard
>