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

[Martin Jansa]

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.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111005/030208d4/attachment-0002.sig>