On Wed, Oct 5, 2011 at 6:02 AM, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> 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 <ota...@ossystems.com.br>
>> > het volgende geschreven:
>> >
>> > > On Wed, Oct 5, 2011 at 09:22, Koen Kooi <k...@dominion.thruhere.net>
>> > > wrote:
>> > >> Op 5 okt. 2011 om 07:10 heeft Otavio Salvador <ota...@ossystems.com.br>
>> > >> het volgende geschreven:
>> > >>> On Tue, Oct 4, 2011 at 19:00, Richard Purdie
>> > >>> <richard.pur...@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.
I think if there are more than one usecases then moving it to
meta-retired or some such
would be ok otherwise I am of opinion that it should be part of distro
layer which wants to use it
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
