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 --]
WARNING: multiple messages have this Message-ID (diff)
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: [OE-core] 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 --]
next prev parent reply other threads:[~2013-02-12 19:35 UTC|newest]
Thread overview: 49+ 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-11 17:50 ` [OE-core] " Otavio Salvador
2013-02-12 8:38 ` Anders Darander
2013-02-12 8:38 ` [OE-core] " Anders Darander
2013-02-11 22:35 ` Richard Purdie
2013-02-11 22:35 ` [OE-core] " Richard Purdie
2013-02-12 9:24 ` Paul Eggleton
2013-02-12 9:24 ` [OE-core] " Paul Eggleton
2013-02-12 13:10 ` Richard Purdie
2013-02-12 13:10 ` [OE-core] " Richard Purdie
2013-02-12 13:38 ` Paul Eggleton
2013-02-12 13:38 ` [OE-core] " Paul Eggleton
2013-02-12 10:24 ` [oe] " Burton, Ross
2013-02-12 10:24 ` Burton, Ross
2013-02-12 10:38 ` [oe] " Paul Eggleton
2013-02-12 10:38 ` [OE-core] " Paul Eggleton
2013-02-12 16:43 ` [oe] " Otavio Salvador
2013-02-12 16:43 ` [OE-core] " Otavio Salvador
2013-02-12 20:51 ` [oe] " Burton, Ross
2013-02-12 20:51 ` [OE-core] " Burton, Ross
2013-02-12 21:22 ` [oe] " Martin Jansa
2013-02-12 21:22 ` [OE-core] " Martin Jansa
2013-02-12 21:36 ` [oe] " Burton, Ross
2013-02-12 21:36 ` [OE-core] " Burton, Ross
2013-02-12 21:40 ` [oe] " Otavio Salvador
2013-02-12 21:40 ` [OE-core] " Otavio Salvador
2013-02-12 21:53 ` [oe] " Eric Bénard
2013-02-12 21:53 ` [OE-core] " Eric Bénard
2013-02-12 22:02 ` [oe] " Burton, Ross
2013-02-12 22:02 ` [OE-core] " Burton, Ross
2013-02-12 15:50 ` [oe] " Ross Burton
2013-02-12 15:50 ` Ross Burton
2013-02-12 16:44 ` [oe] " Otavio Salvador
2013-02-12 16:44 ` [OE-core] " Otavio Salvador
2013-02-12 16:53 ` [oe] " Paul Eggleton
2013-02-12 16:53 ` [OE-core] " Paul Eggleton
2013-02-12 19:19 ` Martin Jansa [this message]
2013-02-12 19:19 ` Martin Jansa
2013-02-12 19:31 ` [oe] " Otavio Salvador
2013-02-12 19:31 ` [OE-core] " Otavio Salvador
2013-02-12 19:32 ` Paul Eggleton
2013-02-12 19:32 ` [OE-core] " Paul Eggleton
2013-02-12 19:51 ` Martin Jansa
2013-02-12 19:51 ` [OE-core] " Martin Jansa
2013-02-12 20:40 ` Marcin Juszkiewicz
2013-02-12 19:32 ` [oe] " Chris Larson
2013-02-12 19:32 ` [OE-core] " Chris Larson
2013-02-12 19:59 ` [oe] " 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 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.