[oe] Yocto Project and OE - Where now?

[Graeme Gregory]

On 19/01/2011 08:46, Frans Meulenbroeks wrote:
> 2011/1/18 Khem Raj <raj.khem at gmail.com>:
>> On Tue, Jan 18, 2011 at 12:48 PM, Tom Rini <tom_rini at mentor.com> wrote:
>>> I think we also agree here.  But what's the rule of thumb(s) we want to
>>> have, to provide enough choice without too much headache?  As I said
>>> elsewhere, .inc files should probably be used a whole lot more, to help with
>>> the problem of recipe bugfixing and N recipes for an app with the problem.
>>>  We should probably also say that in addition to the "keep the last GPLv2+
>>> version around" rule of thumb we should also have a "keep the latest stable
>>> release" around too.  But what else?  To use busybox as an example, do we
>>> really need to keep 1.18.0 and 1.18.1 around when we have 1.18.2?  How about
>>> if we make the delta between the 3 be just the SRC_URI + checksums?
>>
>> Well what to keep around can not be generalized so much. It also
>> depends upon the nature of releases for various packages
>> some packages have a major release and then push out bug fix releases
>> like busy box case you sited but there are packages
>> which only do major releases which can cause compatibility hassles as
>> new interfaces come and old ones are removed etc.
>> so I think it has to be flexible and mostly left to package
>> maintainers discretion as they know the nature of releases most but
>> I like the idea of keeping one GPLv2 release around and 1 latest
>> release around. If a distro pinned a version then that should
>> be considered as well. It is bad to sweep underneath a distros
>> pinnings. Then they have to rebuild and they get problems
>> as they have to make sure that if a package bump happens then they
>> should be able to define an upgrade path
>>
>> Sometimes newer is not always better in case of udev the size has
>> increased over the time and some distro's may not like
>> it and there can be many such scenarios.
>>
> I wholehearthy agree with the proposal that it is left to the package
> maintainers discretion.
> Wrt the GPLv2+ version. I suggest to reflect this in the name.
> E.g. you could have samba and samba-gplv2 (or perhaps samba-gplv2 and
> samba-gplv3). Then it immediately becomes obvious why there are two
> versions.
> Similarly with versions that became a lot fatter over time (which imho
> is a good reason to keep the old version).
I am totally against this idea, it just makes a total mess of the
namespace. We have the ability to put comments in bitbake files use it.

Graeme