[oe] Yocto Project and OE - Where now?

[Tom Rini]

On 01/19/2011 01:46 AM, 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.

And what about packages that have been, well, gently orphaned?  I think 
we need to accept and understand that there will be a class of recipes 
that are simple enough that they don't need nor have spelled out 
maintainers.

> 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.

Put me in the "no" camp here please, we have a LICENSE field for a reason.

-- 
Tom Rini
Mentor Graphics Corporation