[oe] Yocto Project and OE - Where now?

[Frans Meulenbroeks]

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

Frans.