Skip to contentSkip to conversation

libnl: remove RREPLACES and RCONFLICTS for libnl-genl

PATCH In review Robert Yang 3 participants 7 messages Sep 2, 2016 – Sep 3, 2016

lore
Share & tools
lore
#0 lore raw

cover libnl: remove RREPLACES and RCONFLICTS for libnl-genl

Hi RP,

This is based on master-next branch, and can fix:
https://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/932/steps/BuildImages_2/logs/stdio

// Robert

The following changes since commit 3481121c21ea07ff83d3b05439f5442cd921e244:

runqemu: Enable virtio RNG for all platforms (2016-09-02 00:14:34 +0100)

are available in the git repository at:

git://git.openembedded.org/openembedded-core-contrib rbt/libnl
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/libnl

Robert Yang (1):
libnl: remove RREPLACES and RCONFLICTS for libnl-genl

 meta/recipes-support/libnl/libnl_3.2.28.bb | 2 --
 1 file changed, 2 deletions(-)
Signature · 1 line
2.9.0
#1 lore raw

PATCH 1/1 libnl: remove RREPLACES and RCONFLICTS for libnl-genl

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
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@core2_64: conflicted package libnl-genl-3-200-1:3.2.28-r0.0@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)

libnl: fix packaging mistakes

Remove RREPLACES and RCONFLICTS for libnl-genl will fix the problem.

---
 meta/recipes-support/libnl/libnl_3.2.28.bb | 2 --
 1 file changed, 2 deletions(-)
meta/recipes-support/libnl/libnl_3.2.28.bb +0 -2
index 7ddbd40..799962f 100644
@@ -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"
Signature · 1 line
2.9.0
#2 lore raw

GK

Quoted 49 lines · Robert Yang

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
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@core2_64: conflicted package libnl-genl-3-200-1:3.2.28-r0.0@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)

libnl: fix packaging mistakes

Remove RREPLACES and RCONFLICTS for libnl-genl will fix the problem.

---
meta/recipes-support/libnl/libnl_3.2.28.bb | 2 --

1 file changed, 2 deletions(-)
meta/recipes-support/libnl/libnl_3.2.28.bb +0 -0
index 7ddbd40..799962f 100644
@@ -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.*"

meta/recipes-support/libnl/libnl_3.2.28.bb +0 -2
-RREPLACES_${PN}-genl = "libnl-genl2 libnl-genl-3-200"
-RCONFLICTS_${PN}-genl = "libnl-genl2 libnl-genl-3-200"
Signature · 7 lines
2.9.0

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
#3 lore raw
In reply to Robert Yang

Thanks Robert!

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

Quoted 9 lines · Robert Yang

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?

Quoted 6 lines

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:

Quoted 7 lines

Computing transaction...error: Can't install libnl-genl-3-200-1:3.2.28-r0. 0@core2_64: conflicted package libnl-genl-3-200-1:3.2.28-r0.0@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?

Quoted 18 lines

libnl: fix packaging mistakes

Remove RREPLACES and RCONFLICTS for libnl-genl will fix the problem.

---
 meta/recipes-support/libnl/libnl_3.2.28.bb | 2 --

 1 file changed, 2 deletions(-)
meta/recipes- renamed from meta/recipes-support/libnl/libnl_3.2.28.bb +0 -0

support/libnl/libnl_3.2.28.bb
index 7ddbd40..799962f 100644

meta/recipes-support/libnl/libnl_3.2.28.bb +0 -0
@@ -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.*"

meta/recipes-support/libnl/libnl_3.2.28.bb FILES_${PN}-idiag = "${libdir}/libnl-idiag-3.so.*" · line 48

Quoted 2 lines
meta/recipes-support/libnl/libnl_3.2.28.bb +0 -2
-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'

#4 lore raw

Good questions, the libnl-genl2 in provides is introduced by REPLACES_${PN}-genl = "libnl-genl2", so libnl-genl2 should be preserved. And there was no libnl-genl.rpm in the past, but libnl-3-genl.rpm, please see commit message for more info.

Here is the updated patch:

git://git.openembedded.org/openembedded-core-contrib rbt/libnl
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/libnl

Robert Yang (1):
libnl: fix RREPLACES and RCONFLICTS for libnl-genl

Subject: [PATCH 1/1] libnl: fix RREPLACES and RCONFLICTS for libnl-genl

The libnl-genl.rpm provides libnl-genl-3-200 after the following 2 fixes:
libnl: update to v3.2.28
libnl: fix packaging mistakes

$ rpm -qp --provides tmp/deploy/rpm/core2_64/libnl-genl-3-200-3.2.28-r0.4.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
libnl-genl-3-200 = 1:3.2.28-r0.4

Note, the libnl-genl2 is introduced by REPLACES_${PN}-genl = "libnl-genl2".

So that we don't need set libnl-genl-3-200 in the RREPLACES and RCONFLICTS, 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@core2_64: conflicted package libnl-genl-3-200-1:3.2.28-r0.0@lib32_x86 is locked

We didn't meet this error before was because there was no libnl-genl.rpm, but libnl-3-genl.rpm, and it doesn't provide libnl-genl-3-200 by default.

Remove libnl-genl-3-200 from RREPLACES and RCONFLICTS will fix the problem.

---
 meta/recipes-support/libnl/libnl_3.2.28.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
meta/recipes-support/libnl/libnl_3.2.28.bb +2 -2
index 7ddbd40..26982f3 100644
@@ -44,5 +44,5 @@ 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"
+RREPLACES_${PN}-genl = "libnl-genl2"
+RCONFLICTS_${PN}-genl = "libnl-genl2"
Signature · 3 lines
2.9.0

// Robert
Quoted 66 lines · 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...

Quoted 9 lines · Robert Yang

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?

Quoted 6 lines

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:

Quoted 7 lines

Computing transaction...error: Can't install libnl-genl-3-200-1:3.2.28-r0. 0@core2_64: conflicted package libnl-genl-3-200-1:3.2.28-r0.0@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?

Quoted 15 lines

libnl: fix packaging mistakes

Remove RREPLACES and RCONFLICTS for libnl-genl will fix the problem.

---
 meta/recipes-support/libnl/libnl_3.2.28.bb | 2 --
 1 file changed, 2 deletions(-)
meta/recipes- renamed from meta/recipes-support/libnl/libnl_3.2.28.bb +0 -0

support/libnl/libnl_3.2.28.bb
index 7ddbd40..799962f 100644

meta/recipes-support/libnl/libnl_3.2.28.bb FILES_${PN}-idiag = "${libdir}/libnl-idiag-3.so.*" · line 48

Quoted 5 lines
meta/recipes-support/libnl/libnl_3.2.28.bb +0 -2
@@ -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'

#5 lore raw
Quoted 30 lines · Robert Yang

Good questions, the libnl-genl2 in provides is introduced by REPLACES_${PN}-genl = "libnl-genl2", so libnl-genl2 should be preserved. And there was no libnl-genl.rpm in the past, but libnl-3-genl.rpm, please see commit message for more info.

Here is the updated patch:

   git://git.openembedded.org/openembedded-core-contrib rbt/libnl
   http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=
rbt/libnl

Robert Yang (1):
   libnl: fix RREPLACES and RCONFLICTS for libnl-genl

Subject: [PATCH 1/1] libnl: fix RREPLACES and RCONFLICTS for libnl-genl

The libnl-genl.rpm provides libnl-genl-3-200 after the following 2 fixes:
libnl: update to v3.2.28
libnl: fix packaging mistakes

$ rpm -qp --provides 
tmp/deploy/rpm/core2_64/libnl-genl-3-200-3.2.28-r0.4.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
libnl-genl-3-200 = 1:3.2.28-r0.4
Quoted 2 lines

Note, the libnl-genl2 is introduced by REPLACES_${PN}-genl = "libnl- genl2".

Ah, ok. And so is the last line, libnl-genl-3-200, I suppose. (The IPK backend doesn't seem to do that)

Quoted 9 lines

So that we don't need set libnl-genl-3-200 in the RREPLACES and RCONFLICTS, 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@core2_64: conflicted package libnl-genl-3-200-1:3.2.28-r0.0@lib32_x86 is locked

We didn't meet this error before was because there was no libnl-genl.rpm,

                                                            ^^^^^^^^^^^^^^^ Should that be libnl-genl-3-200.rpm ?

Quoted 1 line

but libnl-3-genl.rpm, and it doesn't provide libnl-genl-3-200 by default.

OK.

So now that there is nothing in ${bindir} of the -genl package anymore, it applies the normal package renaming using the SONAME, resulting in libnl- genl-3-200.

Whereas previously it used ${PN}-genl as package name, where PN was set to libnl-3 during package creation. Why was it libnl-3 (why did it not use libnl-3-200 as prefix)?

Cheers,
Andre'

#6 lore raw
Quoted 53 lines · André Draszik
Quoted 30 lines · Robert Yang

Good questions, the libnl-genl2 in provides is introduced by REPLACES_${PN}-genl = "libnl-genl2", so libnl-genl2 should be preserved. And there was no libnl-genl.rpm in the past, but libnl-3-genl.rpm, please see commit message for more info.

Here is the updated patch:

git://git.openembedded.org/openembedded-core-contrib rbt/libnl
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=
rbt/libnl

Robert Yang (1):
libnl: fix RREPLACES and RCONFLICTS for libnl-genl

Subject: [PATCH 1/1] libnl: fix RREPLACES and RCONFLICTS for libnl-genl

The libnl-genl.rpm provides libnl-genl-3-200 after the following 2 fixes:
libnl: update to v3.2.28
libnl: fix packaging mistakes

$ rpm -qp --provides
tmp/deploy/rpm/core2_64/libnl-genl-3-200-3.2.28-r0.4.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
libnl-genl-3-200 = 1:3.2.28-r0.4
Quoted 2 lines

Note, the libnl-genl2 is introduced by REPLACES_${PN}-genl = "libnl- genl2".

Ah, ok. And so is the last line, libnl-genl-3-200, I suppose. (The IPK backend doesn't seem to do that)

Quoted 9 lines

So that we don't need set libnl-genl-3-200 in the RREPLACES and RCONFLICTS, 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@core2_64: conflicted package libnl-genl-3-200-1:3.2.28-r0.0@lib32_x86 is locked

We didn't meet this error before was because there was no libnl-genl.rpm,

                                                            ^^^^^^^^^^^^^^^

Should that be libnl-genl-3-200.rpm ?

Quoted 1 line

but libnl-3-genl.rpm, and it doesn't provide libnl-genl-3-200 by default.

OK.

Quoted 7 lines

So now that there is nothing in ${bindir} of the -genl package anymore, it applies the normal package renaming using the SONAME, resulting in libnl- genl-3-200.

Whereas previously it used ${PN}-genl as package name, where PN was set to libnl-3 during package creation. Why was it libnl-3 (why did it not use libnl-3-200 as prefix)?

The rename is done by debian.bbclass, you can take a look into it.

// Robert

Quoted 5 lines

Cheers,
Andre'