Re: [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

On Wed, Oct 05, 2011 at 07:29:10AM -0500, Koen Kooi wrote:
> 
> 
> Op 5 okt. 2011 om 07:27 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
> 
> > On Wed, Oct 5, 2011 at 09:22, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >> Op 5 okt. 2011 om 07:10 heeft Otavio Salvador <otavio@ossystems.com.br> het volgende geschreven:
> >>> On Tue, Oct 4, 2011 at 19:00, Richard Purdie
> >>> <richard.purdie@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@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]