Op 18 jan 2011, om 09:05 heeft Otavio Salvador het volgende geschreven: > On Tue, Jan 18, 2011 at 05:21, Graeme Gregory <[email protected]> wrote: >> On 17/01/2011 19:01, Frans Meulenbroeks wrote: >>> - where possible stick to one recipe per package. This reduces the >>> maintenance work and reduces the QA nightmare of lots of different >>> permutations. >>> I feel one recipe per package should be the common case for >>> applications, and preferably also for libs (although I am well aware >>> that especially in the latter case multiple versions cannot always be >>> avoided). >> >> OE is not a distro so this is a non starter already, please don't bog >> down this discussion by re-opening this again. Angstrom 2008, Angstrom >> 2010, kaelios and slugos are all released distributions with different >> versions of apps just as a starter and they arent even near the total >> number of distros in OE. > > I disagree. I think having too many versions of a package just makes > difficult to get things done: > > - it increases the amount of maintainence work; > - has a bigger time to get bugs spoted; > > Users of old distros ought to use a specific repository and branch. > Master ought to be kept clean for 'next distro release'.
I've been using yocto for a few months and I *&#(@$*$(*$($@#($@ hate their 1 version per recipe policy. Every monday I have a working image and every wednesday I have to rebuild from scratch and reevaluate because various things got removed and "upgraded". And since my distro pin file is in a layer, pinnings don't get noticed. So instead of "building on top" of the metadata I need to resort to "fork" the metadata. And I'm not the only one seeing this problem, the yocto autobuilder is almost perputally red :( Having 10 versions is too much, but having 3 (oldstable, stable, development) shouldn't be a problem, especially if they use a common .inc file. Just look at glib-2.0 in yocto. There's only one version, and that's 2.27.5, which is a development release (odd minor number). That's not what I want to use in a distro I need to support, especially looking at the huge API changes going into the 2.27 series. Similar thing for QT, I don't want 4.6.x to suddenly disappear and be forced to use 4.7.x. I also don't want to move 4.6.x to a distro layer, since QT is way too huge to support on your own. Or eglibc or gcc or binuils regards, Koen _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
