[RFC] remove neon from oe-core

[RFC] remove neon from oe-core

[Burton, Ross]

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

Hi,

Since Subversion moved away from neon it appears the only user of it in
oe-core is GStreamer as a HTTP client plugin.  By virtue of being
maintained I suspect the libsoup plugin is generally the better choice
there, so as neon is now unmaintained upstream (last release September
2014, doesn't work with latest GnuTLS release) I propose moving it to
meta-oe.

Any comments?

Ross

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

Re: [RFC] remove neon from oe-core

[akuster808]

Sounds good to me.

- armin

On 06/09/2015 12:14 PM, Burton, Ross wrote:
> Hi,
>
> Since Subversion moved away from neon it appears the only user of it in
> oe-core is GStreamer as a HTTP client plugin.  By virtue of being
> maintained I suspect the libsoup plugin is generally the better choice
> there, so as neon is now unmaintained upstream (last release September
> 2014, doesn't work with latest GnuTLS release) I propose moving it to
> meta-oe.
>
> Any comments?
>
> Ross
>
>

Re: [RFC] remove neon from oe-core

[Paul Eggleton]

Hi Ross,

On Tuesday 09 June 2015 20:14:15 Burton, Ross wrote:
> Since Subversion moved away from neon it appears the only user of it in
> oe-core is GStreamer as a HTTP client plugin.  By virtue of being
> maintained I suspect the libsoup plugin is generally the better choice
> there, so as neon is now unmaintained upstream (last release September
> 2014, doesn't work with latest GnuTLS release) I propose moving it to
> meta-oe.
> 
> Any comments?

I have to be honest and say I don't like meta-oe continuing to be a dumping 
ground for old things that only a few (or no) people are using - if we must 
keep these recipes around, I'd rather they go into a different layer even if 
that layer's only grouping factor is "legacy items", at least then they are 
labelled appropriately. GStreamer 0.10 and BlueZ 4 were recent examples, 
perhaps I should have spoken up earlier, although I don't necessarily think 
it's too late.

Martin - what do you think?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [RFC] remove neon from oe-core

[Burton, Ross]

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

On 10 June 2015 at 10:17, Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:

> I have to be honest and say I don't like meta-oe continuing to be a dumping
> ground for old things that only a few (or no) people are using - if we must
> keep these recipes around, I'd rather they go into a different layer even
> if
> that layer's only grouping factor is "legacy items", at least then they are
> labelled appropriately. GStreamer 0.10 and BlueZ 4 were recent examples,
> perhaps I should have spoken up earlier, although I don't necessarily think
> it's too late.
>
> Martin - what do you think?
>

A meta-legacy layer does have a certain appeal as it would clearly indicate
that these recipes are unmaintained.  That won't really apply for neon
though - libmusicbrainz in meta-multimedia is still useful/in active
development and depends on neon.

Ross

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

Re: [RFC] remove neon from oe-core

[Martin Jansa]

On Wed, Jun 10, 2015 at 10:17:53AM +0100, Paul Eggleton wrote:
> Hi Ross,
> 
> On Tuesday 09 June 2015 20:14:15 Burton, Ross wrote:
> > Since Subversion moved away from neon it appears the only user of it in
> > oe-core is GStreamer as a HTTP client plugin.  By virtue of being
> > maintained I suspect the libsoup plugin is generally the better choice
> > there, so as neon is now unmaintained upstream (last release September
> > 2014, doesn't work with latest GnuTLS release) I propose moving it to
> > meta-oe.
> > 
> > Any comments?
> 
> I have to be honest and say I don't like meta-oe continuing to be a dumping 
> ground for old things that only a few (or no) people are using - if we must 
> keep these recipes around, I'd rather they go into a different layer even if 
> that layer's only grouping factor is "legacy items", at least then they are 
> labelled appropriately. GStreamer 0.10 and BlueZ 4 were recent examples, 
> perhaps I should have spoken up earlier, although I don't necessarily think 
> it's too late.
> 
> Martin - what do you think?

Yes, meta-legacy not included in my world builds looks much better than
dumping untested changes to meta-oe (both gstreamer-0.10 and bluez-4
dumps didn't even parse in form how they were sent to oe-devel ML).

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

Re: [RFC] remove neon from oe-core

[Burton, Ross]

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

On 10 June 2015 at 11:03, Martin Jansa <martin.jansa@gmail.com> wrote:

> Yes, meta-legacy not included in my world builds looks much better than
> dumping untested changes to meta-oe (both gstreamer-0.10 and bluez-4
> dumps didn't even parse in form how they were sent to oe-devel ML).
>

The patches not parsing is obviously a bad thing, I'll try and ensure that
doesn't happen again.

Ross

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