[OE-core] [PATCH 1/1] libnl: remove RREPLACES and RCONFLICTS for libnl-genl

[André Draszik]

Thanks Robert!

For my eduction, I don't understand this yet, though, and I don't want to
cause issues like this again...

On Do, 2016-09-01 at 22:30 -0700, Robert Yang wrote:
> The libnl-genl.rpm provides libnl-genl2 and libnl-genl-3-200:
> 
> $ rpm -qp --provides tmp/deploy/rpm/core2_64/libnl-genl-3-200-3.2.28-
> r0.2.core2_64.rpm
> elf(buildid) = 4e753b2361ba0b02f162244a87cc0680796e46cc
> libnl-genl = 3.2.28
> libnl-genl-3.so.200()(64bit)
> libnl-genl-3.so.200(libnl_3)(64bit)
> libnl-genl2

How does RPM manage to add a provides of libnl-genl2 here?

> libnl-genl-3-200 = 1:3.2.28-r0.2
> 
> so that we don't need set them in the RREPLACES and RCONFLICTS, the
> package manager can handle it, otherwise it would cause do_rootfs errors
> when install both libnl-genl.rpm and lib32-libnl-genl.rpm:
> 
> Computing transaction...error: Can't install libnl-genl-3-200-1:3.2.28-r0.
> 0 at core2_64: conflicted package libnl-genl-3-200-1:3.2.28-r0.0 at lib32_x86 is
> locked
> 
> We didn't meet the error before was because there was no libnl-genl.rpm,
> so that it had no effect, but now the following commit fixed the
> packaging problem: (master-next branch)

Hm, there has been a libnl-genl.ipk all the time. Why no rpm?

> libnl: fix packaging mistakes
> 
> Remove RREPLACES and RCONFLICTS for libnl-genl will fix the problem.
> 
> Signed-off-by: Robert Yang <liezhi.yang at windriver.com>
> ---
>  meta/recipes-support/libnl/libnl_3.2.28.bb | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/meta/recipes-support/libnl/libnl_3.2.28.bb b/meta/recipes-
> support/libnl/libnl_3.2.28.bb
> index 7ddbd40..799962f 100644
> --- a/meta/recipes-support/libnl/libnl_3.2.28.bb
> +++ b/meta/recipes-support/libnl/libnl_3.2.28.bb
> @@ -44,5 +44,3 @@ FILES_${PN}-idiag = "${libdir}/libnl-idiag-3.so.*"
>  FILES_${PN}-nf    = "${libdir}/libnl-nf-3.so.*"
>  FILES_${PN}-route = "${libdir}/libnl-route-3.so.*"
>  FILES_${PN}-xfrm  = "${libdir}/libnl-xfrm-3.so.*"
> -RREPLACES_${PN}-genl = "libnl-genl2 libnl-genl-3-200"
> -RCONFLICTS_${PN}-genl = "libnl-genl2 libnl-genl-3-200"

I can see how 'libnl-genl-3-200' could be an issue with RPM based systems
(whereas libnl-genl2 shouldn't be a problem, except that RPM seems to add
that as a provides???) But I don't understand how this wasn't a problem
before?

What am I missing?

Cheers,
Andre'