From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/2] Remove older GTK+ versions
Date: Fri, 17 Aug 2012 14:08:27 +0100 [thread overview]
Message-ID: <24461155.kAEotVvaST@helios> (raw)
In-Reply-To: <20120817125427.GK3625@jama.jama.net>
On Friday 17 August 2012 14:54:27 Martin Jansa wrote:
> On Fri, Aug 17, 2012 at 01:48:45PM +0100, Paul Eggleton wrote:
> > This is also undesirable for meta-oe IMHO - as a general principle,
> > meta-oe
> > shouldn't be trying to both add additional recipes *and* provide
> > newer/older versions of recipes that are in OE-Core. Please, let's get
> > the new versions into OE-Core or if they're too risky/broken for some use
> > cases for that, then they belong in people's distro layers. (Practically
> > I don't think there are that many instances of new versions of OE-Core
> > recipes that people want to use that would be actually rejected by
> > OE-Core).
>
> What if newer version is needed for recipe which exists only in meta-oe?
>
> I had this in meta-efl where webkit-efl was sometimes segfaulting when
> older stable version of libsoup2.4 was used, upstream solved that by
> recommending development version of libsoup2.4, but as soon as I've
> added it to meta-efl everybody (including users which don't use
> webkit-efl from meta-efl - don't need this libsoup2.4) got it as
> default.
>
> Yes I could have added this libsoup2.4 only to meta-shr (where I had
> P_V for that) and keep webkit-efl broken for everyone else, or try to
> add developement version of libsoup2.4 to oe-core..
That is an unfortunate situation - surely one possible solution though would
be to backport the actual patch that fixes the problem to the version of the
library in OE-Core until the development version of the library gets released?
Alternatively, in certain cases of poorly maintained upstreams where releases
are infrequent, we have just switched to the development version at a chosen
revision in OE-Core (after sufficient testing, naturally).
I appreciate there are going to be outliers, but I think the majority of
situations could be handled without making meta-oe introduce unexpected
changes when it is enabled on top of OE-Core.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
prev parent reply other threads:[~2012-08-17 13:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-17 11:35 [PATCH 0/2] Remove older GTK+ versions Ross Burton
2012-08-17 11:35 ` [PATCH 1/2] gtk+: remove 2.12.7 Ross Burton
2012-08-17 11:35 ` [PATCH 2/2] gtk+ remove 2.16.6 Ross Burton
2012-08-17 12:05 ` [PATCH 0/2] Remove older GTK+ versions Richard Purdie
2012-08-17 12:27 ` Paul Eggleton
2012-08-17 12:30 ` Martin Jansa
2012-08-17 12:32 ` Paul Eggleton
2012-08-17 12:39 ` Martin Jansa
2012-08-17 12:48 ` Paul Eggleton
2012-08-17 12:54 ` Martin Jansa
2012-08-17 12:56 ` Martin Jansa
2012-08-17 13:08 ` Paul Eggleton [this message]
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=24461155.kAEotVvaST@helios \
--to=paul.eggleton@linux.intel.com \
--cc=martin.jansa@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox