On Wednesday 11 February 2015 12:25:06 Burton, Ross wrote: > On 11 February 2015 at 00:17, Paul Gortmaker <[email protected]> > 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
