[OE-core] [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate

Richard Purdie richard.purdie at linuxfoundation.org
Wed Oct 5 13:02:50 UTC 2011


On Wed, 2011-10-05 at 14:34 +0200, Martin Jansa wrote:
> On Wed, Oct 05, 2011 at 07:29:10AM -0500, Koen Kooi wrote:
> > 
> > 
> > Op 5 okt. 2011 om 07:27 heeft Otavio Salvador <otavio at ossystems.com.br> het volgende geschreven:
> > 
> > > On Wed, Oct 5, 2011 at 09:22, Koen Kooi <koen at dominion.thruhere.net> wrote:
> > >> Op 5 okt. 2011 om 07:10 heeft Otavio Salvador <otavio at ossystems.com.br> het volgende geschreven:
> > >>> On Tue, Oct 4, 2011 at 19:00, Richard Purdie
> > >>> <richard.purdie at linuxfoundation.org> wrote:
> > >>>> Really? hal doesn't really replace udev though, we can just use udev
> > >>>> directly in place of it for many things now?
> > >>> 
> > >>> Yes, many moved from hal to udev.
> > >>> 
> > >>>> Specifically which applications are people using with dependencies on
> > >>>> hal? As has been pointed out we can fix the xserver and that appears to
> > >>>> be the only thing remaining in OE-Core?
> > >>> 
> > >>> OE-Core can be easily hal-less but I just ask for hal to not be
> > >>> removed from meta data as I and probably others hasn't finish the move
> > >>> to udev yet.
> > >> 
> > >> Put it in your own layer if you need it. No point in keeping obsolete stuff in oe-core.
> > > 
> > > I wouldn't call it obsolete as it is still a valid option to Xorg and
> > > maybe others. So people might want to use it. I use it.
> > 
> > So put it in your own layer, it has no place in oe-core anymore.
> 
> Agreed, that it has no place in oe-core anymore, but not sure if we can
> keep
> CONFIG_MANAGER_OPTION +=
> "${@['--disable-config-hal','--enable-config-hal',''][bb.data.getVar('DISTRO_XORG_CONFIG_MANAGER',d)
> in ['hal']]}"
> 
> in xserver-xorg or we'll force averybody with hal in his layer to
> .bbappend xserver-xorg too.

I don't mind that staying in the xserver recipe config for now, I do
think hal needs to move somewhere other than oe-core though. A
deprecated layer in meta-oe might be one idea which would keep a common
recipe around for now but make it clear its on its way out.

Cheers,

Richard





More information about the Openembedded-core mailing list