All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: Koen Kooi <koen@dominion.thruhere.net>
Subject: Re: [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate
Date: Wed, 05 Oct 2011 14:02:50 +0100	[thread overview]
Message-ID: <1317819780.14671.144.camel@ted> (raw)
In-Reply-To: <20111005123433.GG19366@jama.jama.net>

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@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.

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




  reply	other threads:[~2011-10-05 13:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-30  8:19 [PATCH] Improve handling of 'all' architecture recipes and their interaction with sstate Martin Jansa
2011-09-30 14:15 ` Richard Purdie
2011-09-30 16:46   ` Martin Jansa
2011-09-30 17:09     ` Richard Purdie
2011-09-30 17:12       ` Martin Jansa
2011-10-01 18:48       ` Otavio Salvador
2011-10-04 22:00         ` Richard Purdie
2011-10-04 22:18           ` Koen Kooi
2011-10-05 12:10           ` Otavio Salvador
2011-10-05 12:22             ` Koen Kooi
2011-10-05 12:27               ` Otavio Salvador
2011-10-05 12:29                 ` Koen Kooi
2011-10-05 12:34                   ` Martin Jansa
2011-10-05 13:02                     ` Richard Purdie [this message]
2011-10-05 19:32                       ` Khem Raj
2011-10-01 18:46 ` Otavio Salvador

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1317819780.14671.144.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=koen@dominion.thruhere.net \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.