should perl modules go in oe-core? (possibly python and ruby ones too)
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
Quoted 10 lines · Jesse Zhang
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.
Quoted 7 lines
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
Quoted 10 lines · Jesse Zhang
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.
Quoted 7 lines
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.
Quoted 10 lines · [[OE-core] should perl modules go in oe-core? (possibly python and ruby ones…
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.
Quoted 7 lines
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.
Quoted 9 lines
None of them seems perfect. Is there already some policy?
jesse
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
-Joe MacDonald. :wq