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

Paul Eggleton paul.eggleton at linux.intel.com
Wed Feb 11 13:38:43 UTC 2015


On Wednesday 11 February 2015 12:25:06 Burton, Ross wrote:
> On 11 February 2015 at 00:17, Paul Gortmaker <paul.gortmaker at 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



More information about the Openembedded-core mailing list