* Discovering available Perl modules OR writing recipes for your own
@ 2013-07-24 15:30 mulhern
2013-07-25 11:52 ` Trevor Woerner
2013-07-27 4:03 ` Stewart, David C
0 siblings, 2 replies; 8+ messages in thread
From: mulhern @ 2013-07-24 15:30 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1769 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Discovering available Perl modules OR writing recipes for your own
2013-07-24 15:30 Discovering available Perl modules OR writing recipes for your own mulhern
@ 2013-07-25 11:52 ` Trevor Woerner
2013-07-25 13:25 ` mulhern
2013-07-27 4:03 ` Stewart, David C
1 sibling, 1 reply; 8+ messages in thread
From: Trevor Woerner @ 2013-07-25 11:52 UTC (permalink / raw)
To: mulhern; +Cc: yocto@yoctoproject.org
On 24 July 2013 11:30, mulhern <mulhern@gmail.com> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Discovering available Perl modules OR writing recipes for your own
2013-07-25 11:52 ` Trevor Woerner
@ 2013-07-25 13:25 ` mulhern
2013-07-25 13:44 ` Paul Eggleton
2013-07-25 14:22 ` Trevor Woerner
0 siblings, 2 replies; 8+ messages in thread
From: mulhern @ 2013-07-25 13:25 UTC (permalink / raw)
To: Trevor Woerner; +Cc: yocto@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]
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@linaro.org>wrote:
> On 24 July 2013 11:30, mulhern <mulhern@gmail.com> 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
>
[-- Attachment #2: Type: text/html, Size: 1942 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Discovering available Perl modules OR writing recipes for your own
2013-07-25 13:25 ` mulhern
@ 2013-07-25 13:44 ` Paul Eggleton
2013-07-25 14:22 ` Trevor Woerner
1 sibling, 0 replies; 8+ messages in thread
From: Paul Eggleton @ 2013-07-25 13:44 UTC (permalink / raw)
To: mulhern; +Cc: yocto
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Discovering available Perl modules OR writing recipes for your own
2013-07-25 13:25 ` mulhern
2013-07-25 13:44 ` Paul Eggleton
@ 2013-07-25 14:22 ` Trevor Woerner
2013-07-25 14:57 ` mulhern
1 sibling, 1 reply; 8+ messages in thread
From: Trevor Woerner @ 2013-07-25 14:22 UTC (permalink / raw)
To: mulhern; +Cc: yocto@yoctoproject.org
On 25 July 2013 09:25, mulhern <mulhern@gmail.com> 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) :-)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Discovering available Perl modules OR writing recipes for your own
2013-07-25 14:22 ` Trevor Woerner
@ 2013-07-25 14:57 ` mulhern
0 siblings, 0 replies; 8+ messages in thread
From: mulhern @ 2013-07-25 14:57 UTC (permalink / raw)
To: Trevor Woerner; +Cc: yocto@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
On Thu, Jul 25, 2013 at 10:22 AM, Trevor Woerner
<trevor.woerner@linaro.org>wrote:
> On 25 July 2013 09:25, mulhern <mulhern@gmail.com> 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
[-- Attachment #2: Type: text/html, Size: 1910 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Discovering available Perl modules OR writing recipes for your own
2013-07-24 15:30 Discovering available Perl modules OR writing recipes for your own mulhern
2013-07-25 11:52 ` Trevor Woerner
@ 2013-07-27 4:03 ` Stewart, David C
2013-07-27 12:24 ` mulhern
1 sibling, 1 reply; 8+ messages in thread
From: Stewart, David C @ 2013-07-27 4:03 UTC (permalink / raw)
To: mulhern, yocto@yoctoproject.org
Did you get an answer? I'm not seeing it.
From: mulhern <mulhern@gmail.com<mailto:mulhern@gmail.com>>
Date: Wednesday, July 24, 2013 8:30 AM
To: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Discovering available Perl modules OR writing recipes for your own
2013-07-27 4:03 ` Stewart, David C
@ 2013-07-27 12:24 ` mulhern
0 siblings, 0 replies; 8+ messages in thread
From: mulhern @ 2013-07-27 12:24 UTC (permalink / raw)
To: Stewart, David C; +Cc: yocto@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]
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/ <http://layers.openembedded.org/layerindex/>
.
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@intel.com> wrote:
> Did you get an answer? I'm not seeing it.
>
> From: mulhern <mulhern@gmail.com>
> Date: Wednesday, July 24, 2013 8:30 AM
> To: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
> 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
>
>
>
[-- Attachment #2: Type: text/html, Size: 3743 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-07-27 12:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-24 15:30 Discovering available Perl modules OR writing recipes for your own mulhern
2013-07-25 11:52 ` Trevor Woerner
2013-07-25 13:25 ` mulhern
2013-07-25 13:44 ` Paul Eggleton
2013-07-25 14:22 ` Trevor Woerner
2013-07-25 14:57 ` mulhern
2013-07-27 4:03 ` Stewart, David C
2013-07-27 12:24 ` mulhern
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.