should perl modules go in oe-core? (possibly python and ruby ones too)

should perl modules go in oe-core? (possibly python and ruby ones too)

[Jesse Zhang]

Hi,

We've accumulated quite a few perl modules and would like to contribute
some/all of them to oe-core. But I think we'd better ask how everyone
thinks before doing so, since the number of the modules are pretty
large, and the policy may as well apply to python/ruby packages.

Most of the modules are simple cpan recipes. They are easy to maintain,
but do consume *some* manpower.

I think there are a few alternatives.

1. decide on each module on a case-by-case basis.

2. keep all of them in some special layer other than oe-core.

3. everyone maintain what they need in-house.

None of them seems perfect. Is there already some policy?

jesse

Re: should perl modules go in oe-core? (possibly python and ruby ones too)

[Richard Purdie]

On Thu, 2013-05-16 at 14:56 +0800, Jesse Zhang wrote:
> We've accumulated quite a few perl modules and would like to contribute
> some/all of them to oe-core. But I think we'd better ask how everyone
> thinks before doing so, since the number of the modules are pretty
> large, and the policy may as well apply to python/ruby packages.
> 
> Most of the modules are simple cpan recipes. They are easy to maintain,
> but do consume *some* manpower.
> 
> I think there are a few alternatives.
> 
> 1. decide on each module on a case-by-case basis.
> 
> 2. keep all of them in some special layer other than oe-core.
> 
> 3. everyone maintain what they need in-house.
> 
> None of them seems perfect. Is there already some policy?

I think the best approach would be to put these into meta-openembedded,
at least at first and then we can think about whether we want to move
any into OE-Core. I don't think we would want to take everything.

Cheers,

Richard

Re: should perl modules go in oe-core? (possibly python and ruby ones too)

[Phil Blundell]

On Thu, 2013-05-16 at 14:56 +0800, Jesse Zhang wrote:
> We've accumulated quite a few perl modules and would like to contribute
> some/all of them to oe-core. But I think we'd better ask how everyone
> thinks before doing so, since the number of the modules are pretty
> large, and the policy may as well apply to python/ruby packages.
> 
> Most of the modules are simple cpan recipes. They are easy to maintain,
> but do consume *some* manpower.
> 
> I think there are a few alternatives.
> 
> 1. decide on each module on a case-by-case basis.
> 
> 2. keep all of them in some special layer other than oe-core.
> 
> 3. everyone maintain what they need in-house.
> 
> None of them seems perfect. Is there already some policy?

As you say, all the options seem to have at least some drawbacks.  I've
been faced with this problem recently when trying to make an updated
recipe for xmltv (which has a vast number of perl dependencies) and
wasn't able to come up with any ideal answer either. 

I think my preference would be to have a dedicated meta-cpan layer which
does nothing other than provide recipes for CPAN modules (or, possibly,
Perl modules in general) and which strives to be a comprehensive
resource for them.  This seems like the only way to avoid ending up with
overlapping sets of modules in different layers, with the consequent
duplication of work and confusion that would result. 

I don't think these modules belong in oe-core: it would be a lot of
recipes (with all the parse time and testing overhead that this entails)
and most oe-core users aren't going to want them.

p.

Re: should perl modules go in oe-core? (possibly python and ruby ones too)

[Joe MacDonald]

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

[[OE-core] should perl modules go in oe-core? (possibly python and ruby ones too)] On 13.05.16 (Thu 14:56) Jesse Zhang wrote:

> Hi,
> 
> We've accumulated quite a few perl modules and would like to contribute
> some/all of them to oe-core. But I think we'd better ask how everyone
> thinks before doing so, since the number of the modules are pretty
> large, and the policy may as well apply to python/ruby packages.
> 
> Most of the modules are simple cpan recipes. They are easy to maintain,
> but do consume *some* manpower.
> 
> I think there are a few alternatives.
> 
> 1. decide on each module on a case-by-case basis.
> 
> 2. keep all of them in some special layer other than oe-core.
> 
> 3. everyone maintain what they need in-house.

Have you considered the possibility of a meta-perl or meta-cpan layer in
meta-openembedded?  It was the first thing that occurred to me and I see
both Phil and Richard making pretty similar suggestions.  There's
already a meta-ruby layer there and it may also help address some of the
perl dependency problems that crop up in recipes in meta-Openembedded.

-J.

> 
> None of them seems perfect. Is there already some policy?
> 
> jesse
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Joe MacDonald.
:wq

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