On Tue, 2011-11-15 at 14:59 +0100, Koen Kooi wrote: > Op 15 nov. 2011, om 14:43 heeft Richard Purdie het volgende geschreven: > > To put this quite simply, I think there is no good reason we shouldn't > > use the mechanism we've selected to handle this kind of problem. We > > should have defaults the reflect backwards compatibility. Other than > > that where is the problem other than a general objection to > > PACKAGECONFIG? > > It forces a choice when there is a solution where things can coexist.
There are multiple ways of coexisting and the configuration changing based on DISTRO_FEATURES doesn't force a choice either. Bottom line is we discussed and agreed a way of handling this and I'd really like to have one preferred way of doing so. IMO the two recipe approach duplicates build time and adds complexity into the recipe which we can avoid using PACKAGECONFIG. Yes that has complexities of its own but the sooner we start experimenting with it, the sooner we'll work through any issues. There are certainly ways we can make things neater. If it really does turn out to be a bad idea we can come up with good reasons why we should get rid of it. FWIW, if you want an example of how badly wrong a two recipe approach can get, see the dpkg/update-alternatives mess I fixed yesterday. Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
