RFC: meta-oe appends and overlayed recipes

RFC: meta-oe appends and overlayed recipes

[Paul Eggleton]

Hi all,

I'd like to make an attempt to remove all appends and overlayed recipes from 
the meta-oe layer. As I've said previously, I don't believe meta-oe - as a 
collection of very useful additional recipes that many wish to be able to use 
on top of their OE-Core based build configurations - should be making any 
possibly unexpected changes to those configurations. Any such changes ought to 
be the province of distro layers alone.

We've already removed all of the obvious overlayed recipes and the meta-
systemd split removed most of the pieces that were there for systemd support; 
there are just a few remaining recipes and appends that need to be dealt with. 
I'll catalogue these below with my comments.

Currently we have the following overlayed recipes:

* icon-naming-utils: meta-oe has a newer version (0.8.90 vs OE-Core's 0.8.7) 
and it uses BBCLASSEXTEND rather than OE-Core's native recipe. I would propose 
to just move the meta-oe version to OE-Core since it appears to be superior.

* libmad: both layers have the same version. The meta-oe version has some 
slightly different versions of the MIPS compiler flag fix and -fforce-mem removal 
patches but I think these can be ignored, since the OE-Core versions of these 
patches have proper headers and are presumably working. The OE-Core version 
has LICENSE_FLAGS that the meta-oe one doesn't, but is missing an avr32-
specific optimisation patch that is in the meta-oe version. What would we do 
with the latter? Is it appropriate to add to the OE-Core recipe?

* tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe that is 
ahead of 1.0; the OE-Core version has two patches not in the meta-oe version 
but that both have been merged upstream in the git revision being used in the 
meta-oe version. There is no newer stable release. What do we do here? Should 
we ask upstream (Chris) for a new stable release?

* xserver-nodm-init: the two versions are quite distinct. Not sure I 
understand the full history here but perhaps someone else can fill in the 
blanks...?

As far as bbappends go we have:

* meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
As far as I can tell this just adds an /etc/busybox-syslog.default file 
containing OPTIONS="-C64" and seems to have been added for systemd support. 
I'm not sure why this wasn't moved to meta-systemd, but I assume it needs to 
be merged into OE-Core now that systemd support is being added there... ?

* meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
Another bbappend apparently for systemd support. Again, this should have been 
moved to meta-systemd; do we now need to merge it into OE-Core?

* meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappend
This is adding qwt to the qte toolchain. As far as I am concerned this is a 
distro policy decision - Qwt is a third-party library that is not part of Qt. 
I believe this should be moved to the layers for whichever distros want this.

* meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
* meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this 
as a distro policy decision; these should move to the layers for whichever 
distros want this. FWIW, this is particularly egregious if you've already 
built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

* meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
Builds against external libav instead of using the builtin copy of ffmpeg, 
apparently for better performance on ARM (and presumably that is not the only 
benefit). It's less clear to me what should be done with this, but I'd still 
rather it could be eliminated. OE-Core does not have ffmpeg/libav; one wonders 
if it should or not.

Thoughts?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: RFC: meta-oe appends and overlayed recipes

[Otavio Salvador]

On Mon, Feb 11, 2013 at 3:09 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
...
> Currently we have the following overlayed recipes:
>
> * icon-naming-utils: meta-oe has a newer version (0.8.90 vs OE-Core's 0.8.7)
> and it uses BBCLASSEXTEND rather than OE-Core's native recipe. I would propose
> to just move the meta-oe version to OE-Core since it appears to be superior.

Agreed.

> * libmad: both layers have the same version. The meta-oe version has some
> slightly different versions of the MIPS compiler flag fix and -fforce-mem removal
> patches but I think these can be ignored, since the OE-Core versions of these
> patches have proper headers and are presumably working. The OE-Core version
> has LICENSE_FLAGS that the meta-oe one doesn't, but is missing an avr32-
> specific optimisation patch that is in the meta-oe version. What would we do
> with the latter? Is it appropriate to add to the OE-Core recipe?

Well maybe clean it and keep the avr32 specific optimization?

> * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe that is
> ahead of 1.0; the OE-Core version has two patches not in the meta-oe version
> but that both have been merged upstream in the git revision being used in the
> meta-oe version. There is no newer stable release. What do we do here? Should
> we ask upstream (Chris) for a new stable release?

It'd be good; in meanwhile we could move meta-oe version to OE-Core.

...
> As far as bbappends go we have:
>
> * meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
> As far as I can tell this just adds an /etc/busybox-syslog.default file
> containing OPTIONS="-C64" and seems to have been added for systemd support.
> I'm not sure why this wasn't moved to meta-systemd, but I assume it needs to
> be merged into OE-Core now that systemd support is being added there... ?

Agreed.

> * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
> Another bbappend apparently for systemd support. Again, this should have been
> moved to meta-systemd; do we now need to merge it into OE-Core?

Agreed.

> * meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappend
> This is adding qwt to the qte toolchain. As far as I am concerned this is a
> distro policy decision - Qwt is a third-party library that is not part of Qt.
> I believe this should be moved to the layers for whichever distros want this.

I think people using qte toolchain ought to comment on it.

> * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this
> as a distro policy decision; these should move to the layers for whichever
> distros want this. FWIW, this is particularly egregious if you've already
> built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

Yes; I think I agree also because *most* people won't use these
backends so better to handle this in the specific
layers/distros/whatever needs it.

> * meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
> Builds against external libav instead of using the builtin copy of ffmpeg,
> apparently for better performance on ARM (and presumably that is not the only
> benefit). It's less clear to me what should be done with this, but I'd still
> rather it could be eliminated. OE-Core does not have ffmpeg/libav; one wonders
> if it should or not.

Dropping it would be a regression IMO so we might try to work in a
solution to OE-Core?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: RFC: meta-oe appends and overlayed recipes

[Anders Darander]

* Otavio Salvador <otavio@ossystems.com.br> [130211 18:50]:

> On Mon, Feb 11, 2013 at 3:09 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> ...
> > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this
> > as a distro policy decision; these should move to the layers for whichever
> > distros want this. FWIW, this is particularly egregious if you've already
> > built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

> Yes; I think I agree also because *most* people won't use these
> backends so better to handle this in the specific
> layers/distros/whatever needs it.

Definitely in favour of this.

That would simplify my own bbappends a lot, by letting me remove quite a
few oe_filter_out's...

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB

Re: RFC: meta-oe appends and overlayed recipes

[Richard Purdie]

On Mon, 2013-02-11 at 17:09 +0000, Paul Eggleton wrote:
> * meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappend
> This is adding qwt to the qte toolchain. As far as I am concerned this is a 
> distro policy decision - Qwt is a third-party library that is not part of Qt. 
> I believe this should be moved to the layers for whichever distros want this.
> 
> * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this 
> as a distro policy decision; these should move to the layers for whichever 
> distros want this. FWIW, this is particularly egregious if you've already 
> built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

If these were implemented as PACKAGECONFIG options, then distros would
just need to set the appropriate PACKAGECONFIG for the package in the
distro config and we wouldn't even need the appends...

Cheers,

Richard

Re: RFC: meta-oe appends and overlayed recipes

[Paul Eggleton]

On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
> On Mon, 2013-02-11 at 17:09 +0000, Paul Eggleton wrote:
> > *
> > meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappe
> > nd This is adding qwt to the qte toolchain. As far as I am concerned this
> > is a distro policy decision - Qwt is a third-party library that is not
> > part of Qt. I believe this should be moved to the layers for whichever
> > distros want this.
> > 
> > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see
> > this as a distro policy decision; these should move to the layers for
> > whichever distros want this. FWIW, this is particularly egregious if
> > you've already built Qt, then add meta-oe and find Qt is being
> > unexpectedly rebuilt.
> If these were implemented as PACKAGECONFIG options, then distros would
> just need to set the appropriate PACKAGECONFIG for the package in the
> distro config and we wouldn't even need the appends...

The thing is the Qt configure options are a little more complicated - many of 
them are three-state switches (enable built-in, enable as a plugin or 
disabled). Thus we've opted to split the configuration options into variables 
for each type. We don't get PACKAGECONFIG's DEPENDS handling, but if we used 
PACKAGECONFIG we'd lose some flexibility.

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: RFC: meta-oe appends and overlayed recipes

[Richard Purdie]

On Tue, 2013-02-12 at 09:24 +0000, Paul Eggleton wrote:
> On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
> > On Mon, 2013-02-11 at 17:09 +0000, Paul Eggleton wrote:
> > > *
> > > meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappe
> > > nd This is adding qwt to the qte toolchain. As far as I am concerned this
> > > is a distro policy decision - Qwt is a third-party library that is not
> > > part of Qt. I believe this should be moved to the layers for whichever
> > > distros want this.
> > > 
> > > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> > > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> > > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see
> > > this as a distro policy decision; these should move to the layers for
> > > whichever distros want this. FWIW, this is particularly egregious if
> > > you've already built Qt, then add meta-oe and find Qt is being
> > > unexpectedly rebuilt.
> > If these were implemented as PACKAGECONFIG options, then distros would
> > just need to set the appropriate PACKAGECONFIG for the package in the
> > distro config and we wouldn't even need the appends...
> 
> The thing is the Qt configure options are a little more complicated - many of 
> them are three-state switches (enable built-in, enable as a plugin or 
> disabled). Thus we've opted to split the configuration options into variables 
> for each type. We don't get PACKAGECONFIG's DEPENDS handling, but if we used 
> PACKAGECONFIG we'd lose some flexibility.

Is there a way we can at least have it behave in a similar way to
PACKAGECONFIG? Can those configuration variables be set from the
distro? 

My main point is that I'd like to not need bbappend files just for
configuration.

Cheers,

Richard

Re: RFC: meta-oe appends and overlayed recipes

[Paul Eggleton]

On Tuesday 12 February 2013 13:10:05 Richard Purdie wrote:
> On Tue, 2013-02-12 at 09:24 +0000, Paul Eggleton wrote:
> > On Monday 11 February 2013 22:35:47 Richard Purdie wrote:
> > > On Mon, 2013-02-11 at 17:09 +0000, Paul Eggleton wrote:
> > > > *
> > > > meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bba
> > > > ppe
> > > > nd This is adding qwt to the qte toolchain. As far as I am concerned
> > > > this
> > > > is a distro policy decision - Qwt is a third-party library that is not
> > > > part of Qt. I believe this should be moved to the layers for whichever
> > > > distros want this.
> > > > 
> > > > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> > > > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> > > > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I
> > > > see
> > > > this as a distro policy decision; these should move to the layers for
> > > > whichever distros want this. FWIW, this is particularly egregious if
> > > > you've already built Qt, then add meta-oe and find Qt is being
> > > > unexpectedly rebuilt.
> > > 
> > > If these were implemented as PACKAGECONFIG options, then distros would
> > > just need to set the appropriate PACKAGECONFIG for the package in the
> > > distro config and we wouldn't even need the appends...
> > 
> > The thing is the Qt configure options are a little more complicated - many
> > of them are three-state switches (enable built-in, enable as a plugin or
> > disabled). Thus we've opted to split the configuration options into
> > variables for each type. We don't get PACKAGECONFIG's DEPENDS handling,
> > but if we used PACKAGECONFIG we'd lose some flexibility.
> 
> Is there a way we can at least have it behave in a similar way to
> PACKAGECONFIG? Can those configuration variables be set from the
> distro?

Well, the default values are set using ?= in qt4.inc, so there's nothing 
stopping them from being set from the distro config.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Burton, Ross]

On 11 February 2013 17:09, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> I'd like to make an attempt to remove all appends and overlayed recipes from
> the meta-oe layer. As I've said previously, I don't believe meta-oe - as a
> collection of very useful additional recipes that many wish to be able to use
> on top of their OE-Core based build configurations - should be making any
> possibly unexpected changes to those configurations. Any such changes ought to
> be the province of distro layers alone.

Hear hear!

> * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe that is
> ahead of 1.0; the OE-Core version has two patches not in the meta-oe version
> but that both have been merged upstream in the git revision being used in the
> meta-oe version. There is no newer stable release. What do we do here? Should
> we ask upstream (Chris) for a new stable release?

Is anyone actually using tslib these days?  oe-core dropped kdrive,
and we don't package the apparently unmaintained input driver for
Xorg.  I guess a new upstream would be good, and then move to meta-oe.

> * xserver-nodm-init: the two versions are quite distinct. Not sure I
> understand the full history here but perhaps someone else can fill in the
> blanks...?

I don't understand the full history either yet, but this is clearly
something that needs to be sorted.

> * meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
> As far as I can tell this just adds an /etc/busybox-syslog.default file
> containing OPTIONS="-C64" and seems to have been added for systemd support.
> I'm not sure why this wasn't moved to meta-systemd, but I assume it needs to
> be merged into OE-Core now that systemd support is being added there... ?

When it's understood *what* that does, then we can evaluate it for oe-core.

> * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
> Another bbappend apparently for systemd support. Again, this should have been
> moved to meta-systemd; do we now need to merge it into OE-Core?

Yes, half of it has been merged to master already. The rest should be
in Radu's branch, we can sort that today.

> * meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
> Builds against external libav instead of using the builtin copy of ffmpeg,
> apparently for better performance on ARM (and presumably that is not the only
> benefit). It's less clear to me what should be done with this, but I'd still
> rather it could be eliminated. OE-Core does not have ffmpeg/libav; one wonders
> if it should or not.

libav/gst-ffmpeg/gst-av (as it's called in gst1.0) has interesting
legal issues, but I do think it should be in oe-core.

Ross

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Paul Eggleton]

On Tuesday 12 February 2013 10:24:50 Burton, Ross wrote:
> > * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
> > that is ahead of 1.0; the OE-Core version has two patches not in the
> > meta-oe version but that both have been merged upstream in the git
> > revision being used in the meta-oe version. There is no newer stable
> > release. What do we do here? Should we ask upstream (Chris) for a new
> > stable release?
> 
> Is anyone actually using tslib these days?  oe-core dropped kdrive,
> and we don't package the apparently unmaintained input driver for
> Xorg.  I guess a new upstream would be good, and then move to meta-oe.

Qt Embedded as we build it is currently configured to use tslib, as is
SDL. If the alternative (evdev?) is supported they could presumably be
switched over though. I don't know how practical that is however.
 
> > * xserver-nodm-init: the two versions are quite distinct. Not sure I
> > understand the full history here but perhaps someone else can fill in the
> > blanks...?
> 
> I don't understand the full history either yet, but this is clearly
> something that needs to be sorted.
> 
> > * meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
> > As far as I can tell this just adds an /etc/busybox-syslog.default file
> > containing OPTIONS="-C64" and seems to have been added for systemd
> > support.
> > I'm not sure why this wasn't moved to meta-systemd, but I assume it needs
> > to be merged into OE-Core now that systemd support is being added
> > there... ?
> When it's understood *what* that does, then we can evaluate it for oe-core.

The following commit introduced this:

http://cgit.openembedded.org/meta-openembedded/commit/?id=c48a6a605c6d8d38cfbc5df39b3dc310bffc07c1

Otavio can you explain further?

> > * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
> > Another bbappend apparently for systemd support. Again, this should have
> > been moved to meta-systemd; do we now need to merge it into OE-Core?
> 
> Yes, half of it has been merged to master already. The rest should be
> in Radu's branch, we can sort that today.

OK, great.

> > * meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
> > Builds against external libav instead of using the builtin copy of ffmpeg,
> > apparently for better performance on ARM (and presumably that is not the
> > only benefit). It's less clear to me what should be done with this, but
> > I'd still rather it could be eliminated. OE-Core does not have
> > ffmpeg/libav; one wonders if it should or not.
> 
> libav/gst-ffmpeg/gst-av (as it's called in gst1.0) has interesting
> legal issues, but I do think it should be in oe-core.

Well, we already have gst-ffmpeg in OE-Core so I can't imagine libav
would be any worse as long as it is similarly protected with
LICENSE_FLAGS.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Otavio Salvador]

On Tue, Feb 12, 2013 at 8:38 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Tuesday 12 February 2013 10:24:50 Burton, Ross wrote:
>> > * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
>> > that is ahead of 1.0; the OE-Core version has two patches not in the
>> > meta-oe version but that both have been merged upstream in the git
>> > revision being used in the meta-oe version. There is no newer stable
>> > release. What do we do here? Should we ask upstream (Chris) for a new
>> > stable release?
>>
>> Is anyone actually using tslib these days?  oe-core dropped kdrive,
>> and we don't package the apparently unmaintained input driver for
>> Xorg.  I guess a new upstream would be good, and then move to meta-oe.
>
> Qt Embedded as we build it is currently configured to use tslib, as is
> SDL. If the alternative (evdev?) is supported they could presumably be
> switched over though. I don't know how practical that is however.

Yes Qt Embedded uses it; not sure evdev is an alternative here.

>> > * xserver-nodm-init: the two versions are quite distinct. Not sure I
>> > understand the full history here but perhaps someone else can fill in the
>> > blanks...?
>>
>> I don't understand the full history either yet, but this is clearly
>> something that needs to be sorted.
>>
>> > * meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
>> > As far as I can tell this just adds an /etc/busybox-syslog.default file
>> > containing OPTIONS="-C64" and seems to have been added for systemd
>> > support.
>> > I'm not sure why this wasn't moved to meta-systemd, but I assume it needs
>> > to be merged into OE-Core now that systemd support is being added
>> > there... ?
>> When it's understood *what* that does, then we can evaluate it for oe-core.
>
> The following commit introduced this:
>
> http://cgit.openembedded.org/meta-openembedded/commit/?id=c48a6a605c6d8d38cfbc5df39b3dc310bffc07c1
>
> Otavio can you explain further?

This was to make the service to use the /etc/default/busybox-syslog to
configure syslog. Today with the availability of journald I not sure
it still has an use. It might be dropped I think.

>> > * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
>> > Another bbappend apparently for systemd support. Again, this should have
>> > been moved to meta-systemd; do we now need to merge it into OE-Core?
>>
>> Yes, half of it has been merged to master already. The rest should be
>> in Radu's branch, we can sort that today.
>
> OK, great.
>
>> > * meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
>> > Builds against external libav instead of using the builtin copy of ffmpeg,
>> > apparently for better performance on ARM (and presumably that is not the
>> > only benefit). It's less clear to me what should be done with this, but
>> > I'd still rather it could be eliminated. OE-Core does not have
>> > ffmpeg/libav; one wonders if it should or not.
>>
>> libav/gst-ffmpeg/gst-av (as it's called in gst1.0) has interesting
>> legal issues, but I do think it should be in oe-core.
>
> Well, we already have gst-ffmpeg in OE-Core so I can't imagine libav
> would be any worse as long as it is similarly protected with
> LICENSE_FLAGS.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre



-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Burton, Ross]

On 12 February 2013 16:43, Otavio Salvador <otavio@ossystems.com.br> wrote:
>> Qt Embedded as we build it is currently configured to use tslib, as is
>> SDL. If the alternative (evdev?) is supported they could presumably be
>> switched over though. I don't know how practical that is however.
>
> Yes Qt Embedded uses it; not sure evdev is an alternative here.

I'd be surprised if QtE doesn't support evdev, but I've been surprised
a lot recently.  Can you investigate quickly to see if QtE supports
evdev?

As far as X and oe-core is concerned, tslib isn't involve at all
anymore.  There are xorg-input-tslib drivers in Debian but they've not
been touched for years, the upstream source URL doesn't exist any
more, and I'd actually be somewhat surprised if they worked.  Xorg is
all about evdev + xinput for touchscreens.

Ross

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Martin Jansa]

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

On Tue, Feb 12, 2013 at 08:51:25PM +0000, Burton, Ross wrote:
> On 12 February 2013 16:43, Otavio Salvador <otavio@ossystems.com.br> wrote:
> >> Qt Embedded as we build it is currently configured to use tslib, as is
> >> SDL. If the alternative (evdev?) is supported they could presumably be
> >> switched over though. I don't know how practical that is however.
> >
> > Yes Qt Embedded uses it; not sure evdev is an alternative here.
> 
> I'd be surprised if QtE doesn't support evdev, but I've been surprised
> a lot recently.  Can you investigate quickly to see if QtE supports
> evdev?
> 
> As far as X and oe-core is concerned, tslib isn't involve at all
> anymore.  There are xorg-input-tslib drivers in Debian but they've not
> been touched for years, the upstream source URL doesn't exist any
> more, and I'd actually be somewhat surprised if they worked.  Xorg is
> all about evdev + xinput for touchscreens.

Yes, xf86-input-tslib works
http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Burton, Ross]

On 12 February 2013 21:22, Martin Jansa <martin.jansa@gmail.com> wrote:
> Yes, xf86-input-tslib works
> http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8

[ surprised face ]

You totally should push those tarballs to a git repo on fd.o,
pengutronix has clearly abandoned it.

In a harsh mood (its 2130 and I'm working) I'm leaning towards making
tslib a packageconfig for qte, and moving tslib into meta-oe...

Ross

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Otavio Salvador]

On Tue, Feb 12, 2013 at 7:36 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 12 February 2013 21:22, Martin Jansa <martin.jansa@gmail.com> wrote:
>> Yes, xf86-input-tslib works
>> http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8
>
> [ surprised face ]
>
> You totally should push those tarballs to a git repo on fd.o,
> pengutronix has clearly abandoned it.
>
> In a harsh mood (its 2130 and I'm working) I'm leaning towards making
> tslib a packageconfig for qte, and moving tslib into meta-oe...

Not if qte does not support evdev; this needs to be checked first or
it'll be a regression.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Eric Bénard]

Hi Ross,

Le Tue, 12 Feb 2013 21:36:16 +0000,
"Burton, Ross" <ross.burton@intel.com> a écrit :

> On 12 February 2013 21:22, Martin Jansa <martin.jansa@gmail.com> wrote:
> > Yes, xf86-input-tslib works
> > http://git.openembedded.org/meta-openembedded/commit/?id=506d5f781f5ee93e3c9b8ca51a7fb65f40d4a8b8
> 
> [ surprised face ]
> 
> You totally should push those tarballs to a git repo on fd.o,
> pengutronix has clearly abandoned it.
> 
> In a harsh mood (its 2130 and I'm working) I'm leaning towards making
> tslib a packageconfig for qte, and moving tslib into meta-oe...
> 
if you have a how-to to get Qt/E 4.x working with evdev, please send it
before removing tslib so that we can test it on several boards which
are actually running with Qt/E+tslib.

Thanks
Eric

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Burton, Ross]

On 12 February 2013 21:53, Eric Bénard <eric@eukrea.com> wrote:
> if you have a how-to to get Qt/E 4.x working with evdev, please send it
> before removing tslib so that we can test it on several boards which
> are actually running with Qt/E+tslib.

Totally, not regressing badly is a prerequisite.

Ross

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Ross Burton]

On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
> > * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
> > Another bbappend apparently for systemd support. Again, this should have been
> > moved to meta-systemd; do we now need to merge it into OE-Core?
> 
> 
> Yes, half of it has been merged to master already. The rest should be
> in Radu's branch, we can sort that today.

I take that back - polkit in oe-core supports systemd if enabled, so this append can be removed. 

Ross

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Otavio Salvador]

On Tue, Feb 12, 2013 at 1:50 PM, Ross Burton <ross.burton@intel.com> wrote:
> On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
>> > * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
>> > Another bbappend apparently for systemd support. Again, this should have been
>> > moved to meta-systemd; do we now need to merge it into OE-Core?
>>
>>
>> Yes, half of it has been merged to master already. The rest should be
>> in Radu's branch, we can sort that today.
>
> I take that back - polkit in oe-core supports systemd if enabled, so this append can be removed.

In fact we cannot drop the bbappend or we break the upgrade path
(except if we bump PR in OE-Core to keep it).

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Paul Eggleton]

On Tuesday 12 February 2013 14:44:58 Otavio Salvador wrote:
> On Tue, Feb 12, 2013 at 1:50 PM, Ross Burton <ross.burton@intel.com> wrote:
> > On Tuesday, 12 February 2013 at 10:24, Burton, Ross wrote:
> >> > * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
> >> > Another bbappend apparently for systemd support. Again, this should
> >> > have been moved to meta-systemd; do we now need to merge it into
> >> > OE-Core?
> >> 
> >> Yes, half of it has been merged to master already. The rest should be
> >> in Radu's branch, we can sort that today.
> > 
> > I take that back - polkit in oe-core supports systemd if enabled, so this
> > append can be removed.
>
> In fact we cannot drop the bbappend or we break the upgrade path
> (except if we bump PR in OE-Core to keep it).

These do need to be dropped; if bumping PR in OE-Core is what has to happen to 
achieve that then so be it.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: RFC: meta-oe appends and overlayed recipes

[Martin Jansa]

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

On Mon, Feb 11, 2013 at 05:09:01PM +0000, Paul Eggleton wrote:
> Hi all,
> 
> I'd like to make an attempt to remove all appends and overlayed recipes from 
> the meta-oe layer. As I've said previously, I don't believe meta-oe - as a 
> collection of very useful additional recipes that many wish to be able to use 
> on top of their OE-Core based build configurations - should be making any 
> possibly unexpected changes to those configurations. Any such changes ought to 
> be the province of distro layers alone.
> 
> We've already removed all of the obvious overlayed recipes and the meta-
> systemd split removed most of the pieces that were there for systemd support; 
> there are just a few remaining recipes and appends that need to be dealt with. 
> I'll catalogue these below with my comments.
> 
> Currently we have the following overlayed recipes:
> 
> * icon-naming-utils: meta-oe has a newer version (0.8.90 vs OE-Core's 0.8.7) 
> and it uses BBCLASSEXTEND rather than OE-Core's native recipe. I would propose 
> to just move the meta-oe version to OE-Core since it appears to be superior.
> 
> * libmad: both layers have the same version. The meta-oe version has some 
> slightly different versions of the MIPS compiler flag fix and -fforce-mem removal 
> patches but I think these can be ignored, since the OE-Core versions of these 
> patches have proper headers and are presumably working. The OE-Core version 
> has LICENSE_FLAGS that the meta-oe one doesn't, but is missing an avr32-
> specific optimisation patch that is in the meta-oe version. What would we do 
> with the latter? Is it appropriate to add to the OE-Core recipe?
> 
> * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe that is 
> ahead of 1.0; the OE-Core version has two patches not in the meta-oe version 
> but that both have been merged upstream in the git revision being used in the 
> meta-oe version. There is no newer stable release. What do we do here? Should 
> we ask upstream (Chris) for a new stable release?

tslib is also requested on devices where kernel driver returns too much
noise, tslib can filter that, evdev needs separate filter like 
http://atrey.karlin.mff.cuni.cz/~metan/evfilter/
but that isn't integrated in OE.

> * xserver-nodm-init: the two versions are quite distinct. Not sure I 
> understand the full history here but perhaps someone else can fill in the 
> blanks...?

The biggest difference is integrated xinput-calibrator and use of
xserver-common_1.34.bb

> As far as bbappends go we have:
> 
> * meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
> As far as I can tell this just adds an /etc/busybox-syslog.default file 
> containing OPTIONS="-C64" and seems to have been added for systemd support. 
> I'm not sure why this wasn't moved to meta-systemd, but I assume it needs to 
> be merged into OE-Core now that systemd support is being added there... ?
> 
> * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
> Another bbappend apparently for systemd support. Again, this should have been 
> moved to meta-systemd; do we now need to merge it into OE-Core?
> 
> * meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappend
> This is adding qwt to the qte toolchain. As far as I am concerned this is a 
> distro policy decision - Qwt is a third-party library that is not part of Qt. 
> I believe this should be moved to the layers for whichever distros want this.
> 
> * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this 
> as a distro policy decision; these should move to the layers for whichever 
> distros want this. FWIW, this is particularly egregious if you've already 
> built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.

MySQL and PostgreSQL are not in oe-core so it cannot be replaced with
simple PACKAGECONFIG option in oe-core recipe, but I also prefer to
share such .bbappend somewhere instead of every distribution reinventing
the wheel when trying to enable something as simple as db in qt.

> * meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
> Builds against external libav instead of using the builtin copy of ffmpeg, 
> apparently for better performance on ARM (and presumably that is not the only 
> benefit). It's less clear to me what should be done with this, but I'd still 
> rather it could be eliminated. OE-Core does not have ffmpeg/libav; one wonders 
> if it should or not.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Otavio Salvador]

On Tue, Feb 12, 2013 at 5:19 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Mon, Feb 11, 2013 at 05:09:01PM +0000, Paul Eggleton wrote:
>> Hi all,
>>
>> I'd like to make an attempt to remove all appends and overlayed recipes from
>> the meta-oe layer. As I've said previously, I don't believe meta-oe - as a
>> collection of very useful additional recipes that many wish to be able to use
>> on top of their OE-Core based build configurations - should be making any
>> possibly unexpected changes to those configurations. Any such changes ought to
>> be the province of distro layers alone.
>>
>> We've already removed all of the obvious overlayed recipes and the meta-
>> systemd split removed most of the pieces that were there for systemd support;
>> there are just a few remaining recipes and appends that need to be dealt with.
>> I'll catalogue these below with my comments.
>>
>> Currently we have the following overlayed recipes:
>>
>> * icon-naming-utils: meta-oe has a newer version (0.8.90 vs OE-Core's 0.8.7)
>> and it uses BBCLASSEXTEND rather than OE-Core's native recipe. I would propose
>> to just move the meta-oe version to OE-Core since it appears to be superior.
>>
>> * libmad: both layers have the same version. The meta-oe version has some
>> slightly different versions of the MIPS compiler flag fix and -fforce-mem removal
>> patches but I think these can be ignored, since the OE-Core versions of these
>> patches have proper headers and are presumably working. The OE-Core version
>> has LICENSE_FLAGS that the meta-oe one doesn't, but is missing an avr32-
>> specific optimisation patch that is in the meta-oe version. What would we do
>> with the latter? Is it appropriate to add to the OE-Core recipe?
>>
>> * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe that is
>> ahead of 1.0; the OE-Core version has two patches not in the meta-oe version
>> but that both have been merged upstream in the git revision being used in the
>> meta-oe version. There is no newer stable release. What do we do here? Should
>> we ask upstream (Chris) for a new stable release?
>
> tslib is also requested on devices where kernel driver returns too much
> noise, tslib can filter that, evdev needs separate filter like
> http://atrey.karlin.mff.cuni.cz/~metan/evfilter/
> but that isn't integrated in OE.
>
>> * xserver-nodm-init: the two versions are quite distinct. Not sure I
>> understand the full history here but perhaps someone else can fill in the
>> blanks...?
>
> The biggest difference is integrated xinput-calibrator and use of
> xserver-common_1.34.bb
>
>> As far as bbappends go we have:
>>
>> * meta-oe/recipes-core/busybox/busybox_1.20.2.bbappend
>> As far as I can tell this just adds an /etc/busybox-syslog.default file
>> containing OPTIONS="-C64" and seems to have been added for systemd support.
>> I'm not sure why this wasn't moved to meta-systemd, but I assume it needs to
>> be merged into OE-Core now that systemd support is being added there... ?
>>
>> * meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
>> Another bbappend apparently for systemd support. Again, this should have been
>> moved to meta-systemd; do we now need to merge it into OE-Core?
>>
>> * meta-oe/recipes-qt/packagegroups/packagegroup-qte-toolchain-target.bbappend
>> This is adding qwt to the qte toolchain. As far as I am concerned this is a
>> distro policy decision - Qwt is a third-party library that is not part of Qt.
>> I believe this should be moved to the layers for whichever distros want this.
>>
>> * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
>> * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
>> These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this
>> as a distro policy decision; these should move to the layers for whichever
>> distros want this. FWIW, this is particularly egregious if you've already
>> built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.
>
> MySQL and PostgreSQL are not in oe-core so it cannot be replaced with
> simple PACKAGECONFIG option in oe-core recipe, but I also prefer to
> share such .bbappend somewhere instead of every distribution reinventing
> the wheel when trying to enable something as simple as db in qt.

So maybe meta-oe ought to add PACKAGECONFIG options?

>> * meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
>> Builds against external libav instead of using the builtin copy of ffmpeg,
>> apparently for better performance on ARM (and presumably that is not the only
>> benefit). It's less clear to me what should be done with this, but I'd still
>> rather it could be eliminated. OE-Core does not have ffmpeg/libav; one wonders
>> if it should or not.
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: RFC: meta-oe appends and overlayed recipes

[Paul Eggleton]

On Tuesday 12 February 2013 20:19:02 Martin Jansa wrote:
> On Mon, Feb 11, 2013 at 05:09:01PM +0000, Paul Eggleton wrote:
> > * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
> > that is ahead of 1.0; the OE-Core version has two patches not in the
> > meta-oe version but that both have been merged upstream in the git
> > revision being used in the meta-oe version. There is no newer stable
> > release. What do we do here? Should we ask upstream (Chris) for a new
> > stable release?
> 
> tslib is also requested on devices where kernel driver returns too much
> noise, tslib can filter that, evdev needs separate filter like
> http://atrey.karlin.mff.cuni.cz/~metan/evfilter/
> but that isn't integrated in OE.

OK. I think the best course of action is to petition upstream for a stable 
release and then update OE-Core to that, then we can drop the recipe from 
meta-oe without ill effect.

> > * xserver-nodm-init: the two versions are quite distinct. Not sure I
> > understand the full history here but perhaps someone else can fill in the
> > blanks...?
> 
> The biggest difference is integrated xinput-calibrator and use of
> xserver-common_1.34.bb

So can you see a means for us to move this into OE-Core? Where are the points 
of conflict?

> > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see
> > this as a distro policy decision; these should move to the layers for
> > whichever distros want this. FWIW, this is particularly egregious if
> > you've already built Qt, then add meta-oe and find Qt is being
> > unexpectedly rebuilt.
>
> MySQL and PostgreSQL are not in oe-core so it cannot be replaced with
> simple PACKAGECONFIG option in oe-core recipe, but I also prefer to
> share such .bbappend somewhere instead of every distribution reinventing
> the wheel when trying to enable something as simple as db in qt.

We kind of discussed this already - PACKAGECONFIG can't work for this  anyway 
because at least for the database drivers it's a tri-state switch. At the 
moment all these bbappends really do is set QT_SQL_DRIVER_FLAGS, DEPENDS and 
set the correct include directory. This is not a particularly advanced 
mechanism, is unlikely to change, and I don't think it's too much to ask for 
this to be set in each distro layer. This is distro policy and should not be 
expressed in meta-oe.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: RFC: meta-oe appends and overlayed recipes

[Martin Jansa]

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

On Tue, Feb 12, 2013 at 07:32:33PM +0000, Paul Eggleton wrote:
> On Tuesday 12 February 2013 20:19:02 Martin Jansa wrote:
> > On Mon, Feb 11, 2013 at 05:09:01PM +0000, Paul Eggleton wrote:
> > > * tslib: OE-Core has the 1.0 release version, meta-oe has a git recipe
> > > that is ahead of 1.0; the OE-Core version has two patches not in the
> > > meta-oe version but that both have been merged upstream in the git
> > > revision being used in the meta-oe version. There is no newer stable
> > > release. What do we do here? Should we ask upstream (Chris) for a new
> > > stable release?
> > 
> > tslib is also requested on devices where kernel driver returns too much
> > noise, tslib can filter that, evdev needs separate filter like
> > http://atrey.karlin.mff.cuni.cz/~metan/evfilter/
> > but that isn't integrated in OE.
> 
> OK. I think the best course of action is to petition upstream for a stable 
> release and then update OE-Core to that, then we can drop the recipe from 
> meta-oe without ill effect.

Agreed,
 
> > > * xserver-nodm-init: the two versions are quite distinct. Not sure I
> > > understand the full history here but perhaps someone else can fill in the
> > > blanks...?
> > 
> > The biggest difference is integrated xinput-calibrator and use of
> > xserver-common_1.34.bb
> 
> So can you see a means for us to move this into OE-Core? Where are the points 
> of conflict?

xinput-calibrator is now being reworked by Andreas so we should at least
wait for this rework to settle down and xserver-common is similar to
formfactor, a bit more flexible but a lot worse to maintain for new
MACHINES (FWIW all local patches are waiting in florian mbox).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

Re: RFC: meta-oe appends and overlayed recipes

[Marcin Juszkiewicz]

W dniu 12.02.2013 20:51, Martin Jansa pisze:

> xserver-common is similar to formfactor, a bit more flexible but a
> lot worse to maintain for new MACHINES

IIRC xserver-common allows to set all MACHINE related variables in
/etc/default/something file. I added that years ago when merged
xserver-common with xserver-kdrive-common with all OE/Poky patches etc.

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Chris Larson]

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

On Tue, Feb 12, 2013 at 12:19 PM, Martin Jansa <martin.jansa@gmail.com>wrote:

> > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
> > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
> > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see
> this
> > as a distro policy decision; these should move to the layers for
> whichever
> > distros want this. FWIW, this is particularly egregious if you've already
> > built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.
>
> MySQL and PostgreSQL are not in oe-core so it cannot be replaced with
> simple PACKAGECONFIG option in oe-core recipe, but I also prefer to
> share such .bbappend somewhere instead of every distribution reinventing
> the wheel when trying to enable something as simple as db in qt.


I don't see any reason the oe-core recipe couldn't provide the
packageconfig options, even missing the dependencies. They are valid
package configuration options, so they should exist in PACKAGECONFIG. If a
distro wants to enable one of them, however, they'd better include the
layers that provide the deps :)
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 1521 bytes --]

Re: [oe] RFC: meta-oe appends and overlayed recipes

[Mark Hatle]

On 2/12/13 1:32 PM, Chris Larson wrote:
>
> On Tue, Feb 12, 2013 at 12:19 PM, Martin Jansa <martin.jansa@gmail.com
> <mailto:martin.jansa@gmail.com>> wrote:
>
>      > * meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.4.bbappend
>      > * meta-oe/recipes-qt/qt4/qt4-embedded_4.8.4.bbappend
>      > These two add MySQL and PostgreSQL support to Qt and Qt/Embedded. I see this
>      > as a distro policy decision; these should move to the layers for whichever
>      > distros want this. FWIW, this is particularly egregious if you've already
>      > built Qt, then add meta-oe and find Qt is being unexpectedly rebuilt.
>
>     MySQL and PostgreSQL are not in oe-core so it cannot be replaced with
>     simple PACKAGECONFIG option in oe-core recipe, but I also prefer to
>     share such .bbappend somewhere instead of every distribution reinventing
>     the wheel when trying to enable something as simple as db in qt.
>
>
> I don't see any reason the oe-core recipe couldn't provide the packageconfig
> options, even missing the dependencies. They are valid package configuration
> options, so they should exist in PACKAGECONFIG. If a distro wants to enable one
> of them, however, they'd better include the layers that provide the deps :)

RPM and Smart integrations both have configuration options that are invalid for 
most configurations or sometimes need additional software provided via a layer. 
  I think this is acceptable, as long as the configuration selects the proper 
DEPENDS/RDEPENDS to ensure the items work properly in the end.

--Mark

> --
> Christopher Larson
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>