1. Topics
  2. Discovering available Perl modules OR writing recipes for your own

Discovering available Perl modules OR writing recipes for your own

mulhern <mulhern@...>
 

Hi all,

I'm working on a recipe for pullledpork, which is a Perl app which grabs and combines Snort rules from various sites.

My questions all revolve around pulledpork's various module dependencies.

pulledpork tries to use the module Crypt::SSLeay and in my current configuration it can't find it. It is very easy to write a little recipes that provides this module and forge ahead.

But I'm not sure that that is the correct thing to do...especially as it looks like I'll have to do the same thing for another ten or so tiny modules if I take that approach.

First, is there some way that I can find out whether that or any particular Perl module is provided by some recipe somewhere? My plan would be to RDEPEND on every available Perl module, forcing them all to be installed in the right place, run the pulledpork script, do the right think to provide any modules still missing until the script can actually complete, and then remove from RDEPENDS all previously included modules that don't show up a values in %INC. So far, so good, but I don't know how to even locate all the Perl modules that are already available.

Second, if the modules really are not available is there a better way to package them up than writing individual recipes for each and every missing module?

Third, are there naming conventions that should be followed? For example there is a recipe for liburi-perl that provides the very simply named Perl module URI.

Thanks!

- mulhern
Trevor Woerner <trevor.woerner@...>
 

On 24 July 2013 11:30, mulhern <mulhern@...> wrote:
pulledpork tries to use the module Crypt::SSLeay and in my current
configuration it can't find it.
It looks like this module has a recipe in the meta-security layer:
http://layers.openembedded.org/layerindex/recipes/?q=perl
mulhern <mulhern@...>
 

Thanks, but that specific module isn't the whole total of my problem. It's nice of you to point out for me the location of that one but what about the more like 15 or so others I didn't list and where they might or might not be hiding? Should that particular module really be in the meta-security layer just because it is meta-security that needed it first? Generally speaking, openssl is really just a networking thing, I think.

My real problem is not that particular module it's that
1) I don't know a good way to find out if all those modules that I need haven't already been packaged up by someone somewhere.
2) I'm not certain that writing a separate recipe for each and every one of those little modules is the correct way to go about getting them all if they aren't already available somewhere.

I guess my third question regarding naming conventions is sort of answered by examples.

- mulhern




On Thu, Jul 25, 2013 at 7:52 AM, Trevor Woerner <trevor.woerner@...> wrote:

On 24 July 2013 11:30, mulhern <mulhern@...> wrote:
> pulledpork tries to use the module Crypt::SSLeay and in my current
> configuration it can't find it.

It looks like this module has a recipe in the meta-security layer:
http://layers.openembedded.org/layerindex/recipes/?q=perl
Paul Eggleton
 

Hi mulhern,

On Thursday 25 July 2013 09:25:04 mulhern wrote:
Thanks, but that specific module isn't the whole total of my problem. It's
nice of you to point out for me the location of that one but what about the
more like 15 or so others I didn't list and where they might or might not
be hiding? Should that particular module really be in the meta-security
layer just because it is meta-security that needed it first?
I think the problem is we still don't have a good home for perl recipes not
needed by anything in OE-Core but that are still useful. I am aware that a
community member is working on a large number of perl recipes for CPAN modules
(Stygia on IRC) but I'm not sure what the current status of that work is.

My real problem is not that particular module it's that
1) I don't know a good way to find out if all those modules that I need
haven't already been packaged up by someone somewhere.
The best way we have for finding these is the recipe search function in the OE
layer index:

http://layers.openembedded.org/layerindex/recipes/

2) I'm not certain that writing a separate recipe for each and every one of
those little modules is the correct way to go about getting them all if
they aren't already available somewhere.
This is the convention we have established. Hopefully with what's in OE-Core,
meta-security and what's coming in the new layer I referred to above we'll on
our way to a sizable portion of the packages available. It might be worth
pinging Stygia to find out how work is going on that layer.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre
Trevor Woerner <trevor.woerner@...>
 

On 25 July 2013 09:25, mulhern <mulhern@...> wrote:
It's
nice of you to point out for me the location of that one but what about the
more like 15 or so others I didn't list and where they might or might not be
hiding?
I was hoping you'd notice that there is a web-based search tool you
can use to try to find various already-written recipes:
http://layers.openembedded.org/layerindex/

If you can't find a module you're interested in through that interface
then you'll have to write it yourself (and hopefully contribute it
back to the community) :-)
mulhern <mulhern@...>
 




On Thu, Jul 25, 2013 at 10:22 AM, Trevor Woerner <trevor.woerner@...> wrote:
On 25 July 2013 09:25, mulhern <mulhern@...> wrote:
> It's
> nice of you to point out for me the location of that one but what about the
> more like 15 or so others I didn't list and where they might or might not be
> hiding?

I was hoping you'd notice that there is a web-based search tool you
can use to try to find various already-written recipes:
http://layers.openembedded.org/layerindex/

I did. It's only as good as the occasionally inaccurate description strings, though. I was hoping for something more programmatic and less susceptible to programmer error.

If you can't find a module you're interested in through that interface
then you'll have to write it yourself (and hopefully contribute it
back to the community) :-)

I'm interning for Yocto this summer, so I think that withholding isn't an option ;) But I don't want to litter the project with unnecessary and redundant recipe files.

- mulhern 

 
David Stewart
 

Did you get an answer? I'm not seeing it.

From: mulhern <mulhern@...<mailto:mulhern@...>>
Date: Wednesday, July 24, 2013 8:30 AM
To: "yocto@...<mailto:yocto@...>" <yocto@...<mailto:yocto@...>>
Subject: [yocto] Discovering available Perl modules OR writing recipes for your own

Hi all,

I'm working on a recipe for pullledpork, which is a Perl app which grabs and combines Snort rules from various sites.

My questions all revolve around pulledpork's various module dependencies.

pulledpork tries to use the module Crypt::SSLeay and in my current configuration it can't find it. It is very easy to write a little recipes that provides this module and forge ahead.

But I'm not sure that that is the correct thing to do...especially as it looks like I'll have to do the same thing for another ten or so tiny modules if I take that approach.

First, is there some way that I can find out whether that or any particular Perl module is provided by some recipe somewhere? My plan would be to RDEPEND on every available Perl module, forcing them all to be installed in the right place, run the pulledpork script, do the right think to provide any modules still missing until the script can actually complete, and then remove from RDEPENDS all previously included modules that don't show up a values in %INC. So far, so good, but I don't know how to even locate all the Perl modules that are already available.

Second, if the modules really are not available is there a better way to package them up than writing individual recipes for each and every missing module?

Third, are there naming conventions that should be followed? For example there is a recipe for liburi-perl that provides the very simply named Perl module URI.

Thanks!

- mulhern
mulhern <mulhern@...>
 

I think the high level summary is:

1. You can look and see if the module is in open-embedded by checking at http://layers.openembedded.org/.
2. You're supposed to make a separate recipe for every little module.

- mulhern


On Sat, Jul 27, 2013 at 12:03 AM, Stewart, David C <david.c.stewart@...> wrote:
Did you get an answer? I'm not seeing it.

From: mulhern <mulhern@...>
Date: Wednesday, July 24, 2013 8:30 AM
To: "yocto@..." <yocto@...>
Subject: [yocto] Discovering available Perl modules OR writing recipes for your own

Hi all,

I'm working on a recipe for pullledpork, which is a Perl app which grabs and combines Snort rules from various sites.

My questions all revolve around pulledpork's various module dependencies.

pulledpork tries to use the module Crypt::SSLeay and in my current configuration it can't find it. It is very easy to write a little recipes that provides this module and forge ahead.

But I'm not sure that that is the correct thing to do...especially as it looks like I'll have to do the same thing for another ten or so tiny modules if I take that approach.

First, is there some way that I can find out whether that or any particular Perl module is provided by some recipe somewhere? My plan would be to RDEPEND on every available Perl module, forcing them all to be installed in the right place, run the pulledpork script, do the right think to provide any modules still missing until the script can actually complete, and then remove from RDEPENDS all previously included modules that don't show up a values in %INC. So far, so good, but I don't know how to even locate all the Perl modules that are already available.

Second, if the modules really are not available is there a better way to package them up than writing individual recipes for each and every missing module?

Third, are there naming conventions that should be followed? For example there is a recipe for liburi-perl that provides the very simply named Perl module URI.

Thanks!

- mulhern

1 - 8 of 8