<div dir="ltr"><div dir="ltr"><div dir="auto"><br></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 22, 2019 at 4:21 AM Alexander Kanavin <<a href="mailto:alex.kanavin@gmail.com" target="_blank">alex.kanavin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm not sure that would work, as at do_rootfs time both createrepo_c<br>
(v2 user) and libdnf (v1 user) need to be present in the<br>
sysroot-native, and so v1 and v2 files would clash at that point<br>
(libmodulemd.so would be provided by both).<br>
<br>
I am kind of hoping that libdnf would migrate off v1 to v2, and we<br>
could then simply disable v1 altogether. So far it hasn't happened,<br>
and libdnf update is now also blocked by the c++ code that older<br>
compilers don't like, so I'd leave thing as they are for now.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">conflicts will happen only when dev packages</div><div class="gmail_default" style="font-family:monospace,monospace">are bundled into image.</div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">we probably need something like libusb for this case and then remove the compat package when its</div><div class="gmail_default" style="font-family:monospace,monospace">no longer needed.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Alex<br>
<br>
On Wed, 22 May 2019 at 13:08, Richard Purdie<br>
<<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>> wrote:<br>
><br>
> On Wed, 2019-05-22 at 12:28 +0200, Alexander Kanavin wrote:<br>
> > On Wed, 22 May 2019 at 04:04, Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>> wrote:<br>
> > > > +<br>
> > > > + pkg.generate(<br>
> > > > +- libraries : modulemd_v1_lib,<br>
> > > > ++ libraries : '-l:libmodulemd.so.1',<br>
> > ><br>
> > > shouldn't it be generating a separate package for v1 ?<br>
> > > hardcoding linker paths seems a bit hackish here, is it going<br>
> > > to generate a .pc file with .so.1 version ?<br>
> ><br>
> > The problem is that both v2 and v1 are installed into the sysroot; we<br>
> > don't have a mechanism to choose one or the other via DEPENDS (unlike<br>
> > desktop distros where you can install -v1-dev or -v2-dev package for<br>
> > your build).<br>
> > Then both v2 and v1 .pc files (without this patch) refer to<br>
> > '-lmodulemd' which in our case always resolves to v2 library.<br>
> ><br>
> > Wth the patch the generated v1 .pc will look like this, while v2<br>
> > continues to use the original '-lmodlulemd' in Libs:<br>
> ><br>
> > prefix=${pcfiledir}/../../../usr<br>
> > libdir=${prefix}/lib<br>
> > includedir=${prefix}/include<br>
> ><br>
> > Name: modulemd<br>
> > Description: Module metadata manipulation library<br>
> > Version: 1.8.10<br>
> > Requires: glib-2.0, gobject-2.0<br>
> > Libs: -l:libmodulemd.so.1<br>
> > Cflags: -I${includedir}/modulemd<br>
><br>
> FWIW I think if there were two different recipes we could select which<br>
> was in the sysroot through DEPENDS?<br>
><br>
> Cheers,<br>
><br>
> Richard<br>
><br>
</blockquote></div></div>
</div>