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

2019-05-22 Thread Khem Raj
On Wed, May 22, 2019 at 4:21 AM Alexander Kanavin 
wrote:

> 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.
>
>
conflicts will happen only when dev packages
are bundled into image.

we probably need something like libusb for this case and then remove the
compat package when its
no longer needed.



> Alex
>
> On Wed, 22 May 2019 at 13:08, Richard Purdie
>  wrote:
> >
> > On Wed, 2019-05-22 at 12:28 +0200, Alexander Kanavin wrote:
> > > On Wed, 22 May 2019 at 04:04, Khem Raj  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
> >
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2019-05-22 Thread 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
 wrote:
>
> On Wed, 2019-05-22 at 12:28 +0200, Alexander Kanavin wrote:
> > On Wed, 22 May 2019 at 04:04, Khem Raj  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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2019-05-22 Thread Richard Purdie
On Wed, 2019-05-22 at 12:28 +0200, Alexander Kanavin wrote:
> On Wed, 22 May 2019 at 04:04, Khem Raj  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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2019-05-22 Thread Alexander Kanavin
On Wed, 22 May 2019 at 04:04, Khem Raj  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


Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2019-05-21 Thread Khem Raj
On Tue, May 21, 2019 at 9:12 AM Alexander Kanavin
 wrote:
>
> Signed-off-by: Alexander Kanavin 
> ---
>  ...xplicitly-specify-the-v1-library-in-.patch | 28 +++
>  .../libmodulemd/libmodulemd_git.bb|  1 +
>  2 files changed, 29 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
>
> diff --git 
> a/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
>  
> b/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
> new file mode 100644
> index 000..1568d25f9d8
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
> @@ -0,0 +1,28 @@
> +From b651551134cf170038b3e01812e3767969506491 Mon Sep 17 00:00:00 2001
> +From: Alexander Kanavin 
> +Date: Tue, 21 May 2019 17:59:26 +0200
> +Subject: [PATCH] v1/meson.build: explicitly specify the v1 library in
> + pkgconfig
> +
> +Otherwise there would be '-lmodulemd' which resolves
> +to v2 version if both v2 and v1 are present in the sysroot.
> +
> +Upstream-Status: Pending
> +Signed-off-by: Alexander Kanavin 
> +---
> + modulemd/v1/meson.build | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/modulemd/v1/meson.build b/modulemd/v1/meson.build
> +index 4d54e69..9144ca2 100644
> +--- a/modulemd/v1/meson.build
>  b/modulemd/v1/meson.build
> +@@ -325,7 +325,7 @@ configure_file(
> + )
> +
> + 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 ?

> + subdirs : v1_header_path,
> + version : libmodulemd_v1_version,
> + name : 'modulemd',
> diff --git a/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb 
> b/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
> index d7f486868b8..d4ffd281b5f 100644
> --- a/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
> +++ b/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
> @@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=25a3927bff3ee4f5b21bcb0ed3fcd6bb"
>  SRC_URI = "git://github.com/fedora-modularity/libmodulemd;protocol=https \
> file://0001-spec_tmpl.sh-use-bin-sh-not-usr-bin-sh.patch \
> 
> file://0002-modulemd-v1-meson.build-do-not-generate-gir-or-gtkdo.patch \
> +   
> file://0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch \
> "
>
>  PV = "2.4.0"
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2019-05-21 Thread Alexander Kanavin
Signed-off-by: Alexander Kanavin 
---
 ...xplicitly-specify-the-v1-library-in-.patch | 28 +++
 .../libmodulemd/libmodulemd_git.bb|  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 
meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch

diff --git 
a/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
 
b/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
new file mode 100644
index 000..1568d25f9d8
--- /dev/null
+++ 
b/meta/recipes-devtools/libmodulemd/libmodulemd/0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch
@@ -0,0 +1,28 @@
+From b651551134cf170038b3e01812e3767969506491 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Tue, 21 May 2019 17:59:26 +0200
+Subject: [PATCH] v1/meson.build: explicitly specify the v1 library in
+ pkgconfig
+
+Otherwise there would be '-lmodulemd' which resolves
+to v2 version if both v2 and v1 are present in the sysroot.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+---
+ modulemd/v1/meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/modulemd/v1/meson.build b/modulemd/v1/meson.build
+index 4d54e69..9144ca2 100644
+--- a/modulemd/v1/meson.build
 b/modulemd/v1/meson.build
+@@ -325,7 +325,7 @@ configure_file(
+ )
+ 
+ pkg.generate(
+-libraries : modulemd_v1_lib,
++libraries : '-l:libmodulemd.so.1',
+ subdirs : v1_header_path,
+ version : libmodulemd_v1_version,
+ name : 'modulemd',
diff --git a/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb 
b/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
index d7f486868b8..d4ffd281b5f 100644
--- a/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
+++ b/meta/recipes-devtools/libmodulemd/libmodulemd_git.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=25a3927bff3ee4f5b21bcb0ed3fcd6bb"
 SRC_URI = "git://github.com/fedora-modularity/libmodulemd;protocol=https \
file://0001-spec_tmpl.sh-use-bin-sh-not-usr-bin-sh.patch \

file://0002-modulemd-v1-meson.build-do-not-generate-gir-or-gtkdo.patch \
+   
file://0001-v1-meson.build-explicitly-specify-the-v1-library-in-.patch \
"
 
 PV = "2.4.0"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core