Re: Yocto Project and OE - Where now?

[Koen Kooi <koen@dominion.thruhere.net>]

Op 18 jan 2011, om 09:05 heeft Otavio Salvador het volgende geschreven:

> On Tue, Jan 18, 2011 at 05:21, Graeme Gregory <dp@xora.org.uk> 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