public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-devel@lists.openembedded.org,
	openembedded-core@lists.openembedded.org
Subject: Re: RFC: meta-oe appends and overlayed recipes
Date: Tue, 12 Feb 2013 20:19:02 +0100	[thread overview]
Message-ID: <20130212191902.GD3300@jama> (raw)
In-Reply-To: <2760168.9kFd94gL1F@helios>

[-- 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 --]

  parent reply	other threads:[~2013-02-12 19:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-11 17:09 RFC: meta-oe appends and overlayed recipes Paul Eggleton
2013-02-11 17:50 ` Otavio Salvador
2013-02-12  8:38   ` Anders Darander
2013-02-11 22:35 ` Richard Purdie
2013-02-12  9:24   ` Paul Eggleton
2013-02-12 13:10     ` Richard Purdie
2013-02-12 13:38       ` Paul Eggleton
2013-02-12 10:24 ` [oe] " Burton, Ross
2013-02-12 10:38   ` Paul Eggleton
2013-02-12 16:43     ` Otavio Salvador
2013-02-12 20:51       ` Burton, Ross
2013-02-12 21:22         ` Martin Jansa
2013-02-12 21:36           ` Burton, Ross
2013-02-12 21:40             ` Otavio Salvador
2013-02-12 21:53             ` Eric Bénard
2013-02-12 22:02               ` Burton, Ross
2013-02-12 15:50   ` Ross Burton
2013-02-12 16:44     ` Otavio Salvador
2013-02-12 16:53       ` Paul Eggleton
2013-02-12 19:19 ` Martin Jansa [this message]
2013-02-12 19:31   ` Otavio Salvador
2013-02-12 19:32   ` Paul Eggleton
2013-02-12 19:51     ` Martin Jansa
2013-02-12 20:40       ` Marcin Juszkiewicz
2013-02-12 19:32   ` [oe] " Chris Larson
2013-02-12 19:59     ` Mark Hatle

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=20130212191902.GD3300@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox