[PATCH] avahi: fix do_rootfs failure due to version skew

[PATCH] avahi: fix do_rootfs failure due to version skew

[Paul Gortmaker]

The following failure was observed:

error: libavahi-ui-dev-0.6.31-r11.0 requires avahi-daemon = 0.6.31-r11.0
error: libavahi-ui-dev-0.6.31-r11.0 requires libavahi-core7 = 0.6.31-r11.0
error: libavahi-ui-dev-0.6.31-r11.0 requires libavahi-client3 = 0.6.31-r11.0
ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: poky/build/tmp/work/intel_corei7_64-poky-linux/op3-graphical-builder/0.2-r0/temp/log.do_rootfs.8407

Investigating, one finds the following RPM versions:

op3:~/poky/build/tmp/deploy$ ls -l rpm/*core2*/libavahi*
-rw-r--r-- 2 paul paul  31487 Feb 10 13:15 rpm/core2_64/libavahi-client3-0.6.31-r11.1.core2_64.rpm
-rw-r--r-- 2 paul paul  25974 Feb 10 13:15 rpm/core2_64/libavahi-common3-0.6.31-r11.1.core2_64.rpm
-rw-r--r-- 2 paul paul  98862 Feb 10 13:15 rpm/core2_64/libavahi-core7-0.6.31-r11.1.core2_64.rpm
-rw-r--r-- 2 paul paul   9677 Feb 10 13:15 rpm/core2_64/libavahi-glib1-0.6.31-r11.1.core2_64.rpm
-rw-r--r-- 2 paul paul  22097 Feb 10 13:15 rpm/core2_64/libavahi-gobject0-0.6.31-r11.1.core2_64.rpm
-rw-r--r-- 2 paul paul 123301 Feb 10 13:16 rpm/core2_64/libavahi-ui-dbg-0.6.31-r11.0.core2_64.rpm
-rw-r--r-- 2 paul paul   8721 Feb 10 13:16 rpm/core2_64/libavahi-ui-dev-0.6.31-r11.0.core2_64.rpm
-rw-r--r-- 2 paul paul   4706 Feb 10 13:16 rpm/core2_64/libavahi-ui-doc-0.6.31-r11.0.core2_64.rpm
-rw-r--r-- 2 paul paul  71637 Feb 10 13:16 rpm/core2_64/libavahi-ui-staticdev-0.6.31-r11.0.core2_64.rpm
-rw-r--r-- 2 paul paul  11743 Feb 10 13:16 rpm/core2_64/libavahi-ui-utils-0.6.31-r11.0.core2_64.rpm
-rw-r--r-- 2 paul paul  25517 Feb 10 13:16 rpm/core2_64/libavahi-ui0-0.6.31-r11.0.core2_64.rpm
op3:~/poky/build/tmp/deploy$

Note the difference between r11.0 and r11.1 in the above listing.  That
difference causes the fail because:

op3:~/poky$ git grep EXTE meta/recipes-connectivity/avahi/
meta/recipes-connectivity/avahi/avahi.inc:RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (= ${EXTENDPKGV}) libavahi-client (= ${EXTENDPKGV})"
op3:~/poky$

i.e. we require strict package version matching.  We can see why this version
mismatch happens as follows:

op3:~/poky$ git grep INC meta/recipes-connectivity/avahi/
meta/recipes-connectivity/avahi/avahi-ui_0.6.31.bb:PR = "${INC_PR}.0"
meta/recipes-connectivity/avahi/avahi.inc:INC_PR = "r11"
meta/recipes-connectivity/avahi/avahi_0.6.31.bb:PR = "${INC_PR}.1"
op3:~/poky$

Here, we change the version matching to be more relaxed by stopping at the
INC_PR value, and extending the matching to be greater or equal.

Suggested-by:  Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 meta/recipes-connectivity/avahi/avahi.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
index b060437c1242..7749386b8419 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -102,7 +102,7 @@ FILES_libavahi-glib = "${libdir}/libavahi-glib.so.*"
 FILES_libavahi-gobject = "${libdir}/libavahi-gobject.so.*"
 FILES_avahi-utils = "${bindir}/avahi-*"
 
-RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (= ${EXTENDPKGV}) libavahi-client (= ${EXTENDPKGV})"
+RDEPENDS_${PN}-dev = "avahi-daemon (>= ${PKGV}-${INC_PR}) libavahi-core (>= ${PKGV}-${INC_PR}) libavahi-client (>= ${PKGV}-${INC_PR})"
 
 # uclibc has no nss
 RRECOMMENDS_avahi-daemon_append_libc-glibc = " libnss-mdns"
-- 
2.2.1

Re: [PATCH] avahi: fix do_rootfs failure due to version skew

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Hi Paul,

On 11 February 2015 at 00:17, Paul Gortmaker <paul.gortmaker@windriver.com>
wrote:

> -RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (=
> ${EXTENDPKGV}) libavahi-client (= ${EXTENDPKGV})"
> +RDEPENDS_${PN}-dev = "avahi-daemon (>= ${PKGV}-${INC_PR}) libavahi-core
> (>= ${PKGV}-${INC_PR}) libavahi-client (>= ${PKGV}-${INC_PR})"
>

But this then breaks the hard dependencies for the avahi package.

Basically the problem is that you can't just include complex recipes in
other recipes and expect it to work without lots of hackery.  In this case,
the amount of hackery required to fix this and various other problems (I've
an abandoned branch that sorts out other problems) is arguably more
complicated that throwing all of this away and starting again.

Personally, I don't see why we have avahi and avahi-ui.  Enabling the GTK+
tools should be a PACKAGECONFIG option that is controlled by default by
DISTRO_FEATURES, and all the hackery deleted.

I've got a few branches that implement some of this already, I'll dig them
out as this has been bugging me for a while now.

Ross

[-- Attachment #2: Type: text/html, Size: 1639 bytes --]

Re: [PATCH] avahi: fix do_rootfs failure due to version skew

[Paul Eggleton]

On Wednesday 11 February 2015 12:25:06 Burton, Ross wrote:
> On 11 February 2015 at 00:17, Paul Gortmaker <paul.gortmaker@windriver.com>
> wrote:
> > -RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (=
> > ${EXTENDPKGV}) libavahi-client (= ${EXTENDPKGV})"
> > +RDEPENDS_${PN}-dev = "avahi-daemon (>= ${PKGV}-${INC_PR}) libavahi-core
> > (>= ${PKGV}-${INC_PR}) libavahi-client (>= ${PKGV}-${INC_PR})"
> 
> But this then breaks the hard dependencies for the avahi package.
> 
> Basically the problem is that you can't just include complex recipes in
> other recipes and expect it to work without lots of hackery.  In this case,
> the amount of hackery required to fix this and various other problems (I've
> an abandoned branch that sorts out other problems) is arguably more
> complicated that throwing all of this away and starting again.
> 
> Personally, I don't see why we have avahi and avahi-ui.  Enabling the GTK+
> tools should be a PACKAGECONFIG option that is controlled by default by
> DISTRO_FEATURES, and all the hackery deleted.

A bit short on details, but here's the bug that triggered splitting it in the 
first place:

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=1492

We already had what you're proposing before the split was done. Given that 
avahi is somewhat a core component (if one needs zeroconf), if we go back to 
one recipe, there still needs to be a packaging split between the parts that 
need gtk and those that don't.

(I honestly have to wonder why something like avahi needs its own UI, 
especially in an embedded context, but anyway...)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH] avahi: fix do_rootfs failure due to version skew

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

On 11 February 2015 at 13:38, Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:

> A bit short on details, but here's the bug that triggered splitting it in
> the
> first place:
>
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=1492
>
> We already had what you're proposing before the split was done. Given that
> avahi is somewhat a core component (if one needs zeroconf), if we go back
> to
> one recipe, there still needs to be a packaging split between the parts
> that
> need gtk and those that don't.
>

That's from back when gnome-common had a GPLv3 license, which I've since
fixed upstream.  I've just confirmed that avahi with GPLv3 excluded at
least starts to build.

Ross

[-- Attachment #2: Type: text/html, Size: 1247 bytes --]

Re: [PATCH] avahi: fix do_rootfs failure due to version skew

[Paul Gortmaker]

On 15-02-11 07:25 AM, Burton, Ross wrote:
> Hi Paul,
> 
> On 11 February 2015 at 00:17, Paul Gortmaker <paul.gortmaker@windriver.com>
> wrote:
> 
>> -RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (=
>> ${EXTENDPKGV}) libavahi-client (= ${EXTENDPKGV})"
>> +RDEPENDS_${PN}-dev = "avahi-daemon (>= ${PKGV}-${INC_PR}) libavahi-core
>> (>= ${PKGV}-${INC_PR}) libavahi-client (>= ${PKGV}-${INC_PR})"
>>
> 
> But this then breaks the hard dependencies for the avahi package.
> 
> Basically the problem is that you can't just include complex recipes in
> other recipes and expect it to work without lots of hackery.  In this case,
> the amount of hackery required to fix this and various other problems (I've
> an abandoned branch that sorts out other problems) is arguably more
> complicated that throwing all of this away and starting again.
> 
> Personally, I don't see why we have avahi and avahi-ui.  Enabling the GTK+
> tools should be a PACKAGECONFIG option that is controlled by default by
> DISTRO_FEATURES, and all the hackery deleted.
> 
> I've got a few branches that implement some of this already, I'll dig them
> out as this has been bugging me for a while now.

OK, I'll just keep a local fix for myself as required and leave it
to you guys who have a better understanding of the problem space.

BTW, Is there an open bug I can subscribe to?

Thanks,
Paul.
--

> 
> Ross
>