[oe] Yocto Project and OE - Where now?

[Khem Raj]

On (19/01/11 09: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.
nope, LICENSE field should denote that. Renaming recipes this way does
not look nice.

> Similarly with versions that became a lot fatter over time (which imho
> is a good reason to keep the old version).
> 
> Frans.
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel