On 10/16/2011 11:35 PM, Frans Meulenbroeks wrote:
2011/10/17 Khem Raj<[email protected]>
On Sun, Oct 16, 2011 at 2:37 PM, Andrea Adami<[email protected]>
wrote:
On Sat, Oct 15, 2011 at 8:51 PM,<[email protected]> wrote:
Module: meta-openembedded.git
Branch: master
Commit: 92b02b7209e426a70cc5626e7bdbc82052e01ac5
URL:
http://git.openembedded.org/?p=meta-openembedded.git&a=commit;h=92b02b7209e426a70cc5626e7bdbc82052e01ac5
Author: Khem Raj<[email protected]>
Date: Sun Oct 16 01:28:32 2011 +0000
binutils-cross: Sync with oe-core
Now we have own copy of binutils-cross in meta-oe
I can't unfortunately find the discussion which supposedly provided a
valid
reason for binutils-2.20 in meta-oe while binutils-2.21 is in oe-core.
I'm against that kind of policy for meta-oe, particularly when it's about
toolchain.
oe-core is deprecating versions that are still used by consumers of
meta-oe (mainly angstrom 2010 release)
since its toolchain and it will also benefit derivatives of angstrom.
Angstrom could also move these elements
into meta-angstrom if we think that its only angstrom specific and no
other consumers of oe-core needs them
layer maintainers make judgement call which they think should benefit
wider community
similar but not for binutils here is a relevant thread
I feel if a distro or bsp needs a version of a package that is older than
the oe-core one, it should be stored in the distro or bsp layer.
Or is meta-oe also wanting to keep binutils 18.50? In oe classic this is
used by the nios2 hw (and afaik there is no newer binutils supporting
nios2)? I'd say if some layer needs older versions it is up to them.
This is a bit different when a version is retired from oe-core there
might be more than one bsp using it therefore it would be more
beneficial to keep it in a common layer
What we are lacking here is a policy on purpose/goal of meta-oe and what
goes in (and what not).
This has been discussed quite a bit when we decided to move to layered
structure. meta-oe infact is an umbrella of layers and each layer can
have it own development policies.
Frans
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
