[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