[gentoo-perl] Big Perl Packages and g-cpan

[gentoo-perl] Big Perl Packages and g-cpan

[Michael Higgins]

Hello, List --

Shot in the dark here... anyone on the list using any big, multi-module perl
packages but finding that g-cpan just ain't doin' it for ya?

If so, anyone find a suitable practice to avoid it? (Outside of making an
ebuild, of course.)

I've found that CPAN is just fine to use in the past. But g-cpan doesn't
seem to do much except get in the way when given a build of any real
complexity.

It seems like maybe CPAN.pm could be patched to emerge any modules
maintained the portage when needed by CPAN. If I dump g-cpan, should I also
emerge -C any modules built with portage and build them with CPAN?

Any thoughts or advice much appreciated.

Thanks,

-- 
Michael Higgins


-- 
gentoo-perl@gentoo.org mailing list

Re: [gentoo-perl] Big Perl Packages and g-cpan

[Michael Cummings]

On Mon, 19 Feb 2007 14:16:22 -0800
"Michael Higgins" <mhiggins@banfieldgroup.com> wrote:

> Hello, List --
> 
> Shot in the dark here... anyone on the list using any big,
> multi-module perl packages but finding that g-cpan just ain't doin'
> it for ya?
> 
> If so, anyone find a suitable practice to avoid it? (Outside of
> making an ebuild, of course.)
> 
> I've found that CPAN is just fine to use in the past. But g-cpan
> doesn't seem to do much except get in the way when given a build of
> any real complexity.
> 
> It seems like maybe CPAN.pm could be patched to emerge any modules
> maintained the portage when needed by CPAN. If I dump g-cpan, should
> I also emerge -C any modules built with portage and build them with
> CPAN?
> 
> Any thoughts or advice much appreciated.
> 
> Thanks,
> 
You know, if you gave me an example package I could see about getting
g-cpan working for you ;)


~mike, g-cpan guy

-- 

-----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-----o()o----------------------------------------------
-- 
gentoo-perl@gentoo.org mailing list

RE: [gentoo-perl] Big Perl Packages and g-cpan

[Michael Higgins]

> -----Original Message-----
> From: Michael Cummings [mailto:mcummings@gentoo.org] 
> 
> On Mon, 19 Feb 2007 14:16:22 -0800
> "Michael Higgins" <mhiggins@banfieldgroup.com> wrote:
> 
> > Hello, List --
> > 
> > Shot in the dark here... anyone on the list using any big, 
> > multi-module perl packages but finding that g-cpan just ain't doin'
> > it for ya?
> > 
> > If so, anyone find a suitable practice to avoid it? 
> (Outside of making 
> > an ebuild, of course.)
> > 
> > I've found that CPAN is just fine to use in the past. But g-cpan 
> > doesn't seem to do much except get in the way when given a build of 
> > any real complexity.
> > 
> > It seems like maybe CPAN.pm could be patched to emerge any modules 
> > maintained the portage when needed by CPAN. If I dump 
> g-cpan, should I 
> > also emerge -C any modules built with portage and build them with 
> > CPAN?
> > 
> > Any thoughts or advice much appreciated.
> > 
> > Thanks,
> > 
> You know, if you gave me an example package I could see about 
> getting g-cpan working for you ;)
> 

Heh. ;-)

Hello, Mike -- 

I'd love to spend some time working it out, but I don't have the time right
now. I've got to get some perl stuff installed and working.

So, while I'm on that... maybe this will give you some ideas. ;-)

First, Maypole via g-cpan. Dunno if this helps: 

cat /etc/portage/package.keywords

virtual/perl-Test-Simple ~x86
perl-core/Test-Simple ~x86
dev-perl/DBD-SQLite ~x86
dev-perl/Class-DBI ~x86
dev-perl/libwww-perl ~x86
dev-perl/UNIVERSAL-require ~x86
dev-perl/DBI dev-perl/DBI ~x86
virtual/perl-Sys-Syslog ~x86
perl-core/Sys-Syslog ~x86
virtual/perl-Scalar-List-Utils ~x86
perl-core/Scalar-List-Utils ~x86
virtual/perl-File-Temp ~x86
perl-core/File-Temp ~x86
dev-perl/yaml ~x86
dev-lang/io ~x86
dev-perl/MailTools ~x86
dev-perl/Email-Valid ~x86
dev-perl/Exporter-Lite ~x86
dev-perl/SQL-Abstract ~x86

dev-perl/Apache-Session ~x86
dev-perl/Params-Validate ~x86
dev-perl/Tree-Simple ~x86
dev-perl/Test-Exception ~x86
virtual/perl-File-Spec ~x86
perl-core/File-Spec ~x86

perl-core/IO ~x86
dev-perl/Module-Pluggable ~x86
virtual/perl-Test-Simple ~x86
dev-perl/Test-Simple ~x86


... which is what I had to do just to get started. Why are so many modules
out of date? Why do I need virtuals in here? B/C otherwise the keyword
unmasking fails.

Anyway, after that, I'd love to do CGI::Application (with any and all
related modules).

You see, I'm trying to install application frameworks based on a suite of
perl modules, not individual modules. [ Catalystapplicationframework, FEX,
is maintained in an overlay, but you still have to unmask a gazillion
modules. ]

CPAN might choke eventually on the dependencies for a package like this, but
gcpan... fails with less information... gcpan logging doesn't get you much
error info.

gcpan's CPAN is way out of date too... I have to wonder, why? 

Anyway, I'm just trying to figure out the best route for managing these
installations. CPAN is fine for me, as long as I don't... what... emerge any
modules?

It seemed to me at one point that it might be better, somehow, to just find
a way to patch CPAN to check and emerge any modules in the portage tree...
expect they are often out of date anyway. :(

If one does move away from gcpan, I think one will need to unmerge stuff
from the tree and the overlay. At least, I've been bitten once so far. I
suppose they install in different locations? (No time to check.)

Gosh, I wish I had more time to devote to this now. I'll look forward to
your reply. 

Cheers,

-- 
Michael Higgins



-- 
gentoo-perl@gentoo.org mailing list

Re: [gentoo-perl] Big Perl Packages and g-cpan

[Michael Cummings]

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

On Wed, 21 Feb 2007 13:38:04 -0800
"Michael Higgins" <mhiggins@banfieldgroup.com> wrote:

> > -----Original Message-----
<snip>
> ... which is what I had to do just to get started. Why are so many
> modules out of date? Why do I need virtuals in here? B/C otherwise
> the keyword unmasking fails.

Because the x86 team hasn't unmasked any of these. Other arch's have,
x86 is just behind on these. I know sparc and amd64 are pretty up to
date, and even alpha stays pretty close to the curve, x86 is just slow.
I think they prefer to have stable ticket requests to mark something,
but with 666 modules (roughly) that's more hand holding than I think
we're up to.

FWIW, I just built Maypole using g-cpan-0.15_rc3, no problem.

> CPAN might choke eventually on the dependencies for a package like
> this, but gcpan... fails with less information... gcpan logging
> doesn't get you much error info.

Again, wish you could give something more than "gcan just chokes." If I
can't dup it and can't see what you mean, I can't hope to fix it :) I
have worked pretty hard in the more recent versions of g-cpan to
resolve these dependency issues better, so any examples you can give of
where it's failing would help out a ton.

> 
> gcpan's CPAN is way out of date too... I have to wonder, why? 
> 

Because you never upgraded it...? ;) Seriously, we don't push CPAN as
an ebuild because its not a dep of anything directly, and you can
always g-cpan to bootstrap it to a newer version.

> Anyway, I'm just trying to figure out the best route for managing
> these installations. CPAN is fine for me, as long as I don't...
> what... emerge any modules?


Not sure what you're asking. If you don't want to use g-cpan, don't,
that's pretty simple. g-cpan is for those folks that want some modules,
but want them in the pretty portage architecture. if your more
comfortable using cpan, use cpan. Just don't file bugs about it with
us :) (duh, I know, but you'd be amazed)(or not)
> 
> It seemed to me at one point that it might be better, somehow, to
> just find a way to patch CPAN to check and emerge any modules in the
> portage tree... expect they are often out of date anyway. :(
> 

emerge how? cpan isn't about working with a package manager, any
package manager.

> If one does move away from gcpan, I think one will need to unmerge
> stuff from the tree and the overlay. At least, I've been bitten once
> so far. I suppose they install in different locations? (No time to
> check.)
> 

by default, cpan installs in site. we install in vendor. the reverse
inc patch puts vendor at the top of the food chain, followed by site.
So yes, anything you install by ebuild will trump a cpan install.

> Gosh, I wish I had more time to devote to this now. I'll look forward
> to your reply. 

You shouldn't - i'm tired and crabby and writing when i should be
sleeping, which means i'm being a lot more rude than intended.

~mcummings

-- 

-----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-----o()o----------------------------------------------

Hi, I'm a .signature virus! Please copy me in your ~/.signature.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-perl] Big Perl Packages and g-cpan

[Michael Higgins]

> -----Original Message-----
> From: Michael Cummings [mailto:mcummings@gentoo.org] 
> 
> On Wed, 21 Feb 2007 13:38:04 -0800
> "Michael Higgins" <mhiggins@banfieldgroup.com> wrote:
> 
> > > -----Original Message-----
> <snip>
> > ... which is what I had to do just to get started. Why are so many 
> > modules out of date? Why do I need virtuals in here? B/C 
> otherwise the 
> > keyword unmasking fails.
> 
> Because the x86 team hasn't unmasked any of these. Other arch's have,
> x86 is just behind on these. I know sparc and amd64 are 
> pretty up to date, and even alpha stays pretty close to the 
> curve, x86 is just slow.
> I think they prefer to have stable ticket requests to mark 
> something, but with 666 modules (roughly) that's more hand 
> holding than I think we're up to.

Hmm. So, it's incumbent on the user to unmask all potentially-used
ebuild-available modules? Or, when a module is released to CPAN, maybe a
ticket request needs to go automatically to the x86 folks?

Anyway, to try and fix the issues (and I don't care how, g-cpan -ned or
-less is fine), I've just scripted a bunch of additions to package.keywords
from eix reports of perl modules in portage, hopefully thereby unmasking
anything that might come up as a dependency and is already in portage. 

Now, if I can find a way to loop around g-cpan, simply automatically
unmasking anything it chokes on and making it try again...

Would you take a 'feature request' for that functionality? After all, they
are just perl modules.

And, what do I do when a module comes up in portage, but the latest masked
version is still not satisfying the dependencies? 

Editing an ebuild, wgetting the tarball, digesting and yet knowing it'd be
overwritten at the next sync is about where I got tired of the g-cpan
method. I'm not about wanting to make ebuilds. :(

> 
> FWIW, I just built Maypole using g-cpan-0.15_rc3, no problem.
> 

It wasn't a problem for me either, once I unmasked a bunch of modules. 

Would it be possible to do something like ACCEPT_KEYWORDS='~*' g-cpan blah
and avoid having to stop and unmask the dev-perl/??? and then stop again to
unmask the virtual/perl-???

Of course, that'd probably just be a problem next 'emerge world'. :(

> > CPAN might choke eventually on the dependencies for a package like 
> > this, but gcpan... fails with less information... gcpan logging 
> > doesn't get you much error info.
> 
> Again, wish you could give something more than "gcan just 
> chokes." If I can't dup it and can't see what you mean, I 
> can't hope to fix it :) I have worked pretty hard in the more 

I wasn't looking for a fix, but a workaround. I really don't expect a fix.
;-)

> recent versions of g-cpan to resolve these dependency issues 
> better, so any examples you can give of where it's failing 
> would help out a ton.

Well, rather than get into it, consider this, from the catalystframework
overlay maintainer:

<quote http://forums.gentoo.org/viewtopic-t-419501-highlight-.html>
There's no ebuild in portage for most of the modules, and g-cpan doesn't
always behave well, This is particularly true when attempting the
installation of the Task::Catalyst meta-module, which pulls in almost
everything that is needed to write "serious" applications with Catalyst:
since it uses CPANPLUS, problems come around.
</quote>

So, I don't feel particularly off or unhelpful in saying 'it just chokes'.
"Problems come around" or "doesn't always behave well" are also apt
descriptions. 

Again, I was looking for a workaround, not a fix.

> 
> > 
> > gcpan's CPAN is way out of date too... I have to wonder, why? 
> > 
> 
> Because you never upgraded it...? ;) Seriously, we don't push 
> CPAN as an ebuild because its not a dep of anything directly, 
> and you can always g-cpan to bootstrap it to a newer version.
> 

I never thought to do that. I assumed (reasonably, I think) g-cpan to be
some kind of a front-end to CPAN and, as such, should of course use the
latest version that it's, well, "front-ending". 

But I never looked 'under the hood' and don't expect to.

> > Anyway, I'm just trying to figure out the best route for managing 
> > these installations. CPAN is fine for me, as long as I don't...
> > what... emerge any modules?
> 
> 
> Not sure what you're asking. If you don't want to use g-cpan, 

Asking how to maintain a gentoo/portage system with up-to-date perl modules
added via CPAN, but still able to, say, install mod_perl so that it works
the 'gentoo way' but doesn't clobber my up-to-date CPAN-installed modules.

> don't, that's pretty simple. g-cpan is for those folks that 
> want some modules, but want them in the pretty portage 
> architecture. if your more comfortable using cpan, use cpan. 

It's not that simple. If you emerge anything dependent on any perl module,
portage will install it and CPAN will choke on the out-of-date modules
portage installed, with infinite loops, no "upgrade" option.... aargh.

> Just don't file bugs about it with us :) (duh, I know, but 
> you'd be amazed)(or not)

I thought this was a "user" list. I didn't file a bug, I was hoping someone
out there using perl on gentoo (and maybe even reading the
appropriately-named gentoo-perl mailing list) could help make a transition
away from g-cpan.

My bad, I guess. :(

At this point, it seems the only way would be to put anything perlish in
package.provided to keep portage from emerging perl modules. I may have to
try that, barring some better advice.

> > 
> > It seemed to me at one point that it might be better, 
> somehow, to just 
> > find a way to patch CPAN to check and emerge any modules in the 
> > portage tree... expect they are often out of date anyway. :(
> > 
> 
> emerge how? cpan isn't about working with a package manager, 
> any package manager.

That'd be the 'patch' part. ;-) Specific to portage users...??

> 
> > If one does move away from gcpan, I think one will need to unmerge 
> > stuff from the tree and the overlay. At least, I've been 
> bitten once 
> > so far. I suppose they install in different locations? (No time to
> > check.)
> > 
> 
> by default, cpan installs in site. we install in vendor. the 
> reverse inc patch 

Ah, is this a gentoo-specific patch, then? I do find that whatever portage
installed is preempting my CPAN installs. I imagine this is by design, but,
how necessary is that, really?

> puts vendor at the top of the food chain, 
> followed by site.
> So yes, anything you install by ebuild will trump a cpan install.
> 
> > Gosh, I wish I had more time to devote to this now. I'll 
> look forward 
> > to your reply.
> 
> You shouldn't - i'm tired and crabby and writing when i 
> should be sleeping, which means i'm being a lot more rude 
> than intended.
> 

I don't think you are being at all rude, especially if I was thinking of
contributing as a developer, or was being critical of your work.

But, I'm a lowly user who'd like a solution to a problem that still exists.
I don't feel qualified in any way to be a contributor. I think it's great
that you're working on this stuff. Sometimes folks just want to install a
module, or two, I suppose, and you've given them a nice tool for that.

. . .

Given what you've written, it would seem that removing the reverse @INC
patch would solve the problem as well, no? Portage could install whatever it
wanted, but my CPAN-installed module would be found first, right? 

Is this something I can tweak easily? Would doing that then allow me to use
CPAN and not have portage install older modules that are then found first in
@INC?

Anyway, the upshot is that I still don't have a working, easily replicable
installation of some perl-based application frameworks. It seems the
solution for, for example the catalystframework folk, was to make an ebuild.
And put up a starter list of modules to unmask.

I'm trying to go the g-cpan route again, should I find I need to install any
missing modules, just to see if there's any improvement in the process now
that I've unmasked everything I can find in the portage tree. 

Anyway, I hope you don't find my attempt at exacting language to be terse to
the point of rudeness. I am glad for your feedback so far and would love to
arrive at a solution.

I've been working on a development server, but my production server I'll be
working up soon. It'd just be nice to know that I can replicate an
installation with several perlish development frameworks comprised of
hundreds of perl modules without any hassle as described above. I don't care
what the workaround is.

On another point, with all the CPAN testing going on, is there not some way
to promote newer module versions automatically into portage? Why wouldn't a
good score from CPANTS or CPAN Testers be enough for the x86 devs to fix up
the ebuilds?

Cheers,

-- 
Michael Higgins
IS Specialist
The Banfield Group
Phone: (503) 352-3380 x205
Fax: (503) 352-3389
E-mail: mhiggins@banfieldgroup.com  


-- 
gentoo-perl@gentoo.org mailing list

Re: [gentoo-perl] Big Perl Packages and g-cpan

[Michael Cummings]

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

I know, I'm doing such a great job of responding in a timely fashion :) 

On Wed, Mar 14, 2007 at 02:47:26PM -0700, Michael Higgins wrote:
 
> Hmm. So, it's incumbent on the user to unmask all potentially-used
> ebuild-available modules? Or, when a module is released to CPAN, maybe a
> ticket request needs to go automatically to the x86 folks?

No, it is not incumbent. Since this thread started (I know, there's only been a
few posts to it, but that still counts), I've worked with the x86 folks to bring
the keywords up to date for that platform. As a general rule, barring security
fixes and the like, something should be in the tree for 30-60 days before a
request to mark it stable can be filed. That said, I (and my fellow perl devs)
aren't perfect - its perfectly feasible and likely that we will miss modules
that are worthy of marking stable on your $arch (human volunteers and all that).
You are always welcome, as a user of Gentoo, to submit a bug requesting that
something go stable - if nothing else its a warm fuzzy that people are out there
and using stuff and actually in need of it (vs our guessing that folks are
trying stuff).

> 
> Anyway, to try and fix the issues (and I don't care how, g-cpan -ned or
> -less is fine), I've just scripted a bunch of additions to package.keywords
> from eix reports of perl modules in portage, hopefully thereby unmasking
> anything that might come up as a dependency and is already in portage. 
> 
> Now, if I can find a way to loop around g-cpan, simply automatically
> unmasking anything it chokes on and making it try again...
> 

Believe me, this is a feature I have in mind for 0.16 (0.15 is too far out the
door for this kind of addition). My frame of thought is comparing your
ACCEPT_KEYWORD against the needed ebuild's KEYWORDS and making a copy in your
overlay if necessary. That and actually documenting this disparity between
what's keyworded in the tree and what g-cpan's keyworded....

> Would you take a 'feature request' for that functionality? After all, they
> are just perl modules.

um, done :)

 
> And, what do I do when a module comes up in portage, but the latest masked
> version is still not satisfying the dependencies? 

gripe at us :) those automated emails that get sent are to remind us of what's
getting behind in the tree. We try to tackle them as often as possible - but
other things crop up (i'm done  giving excuses, don't worry)

> Editing an ebuild, wgetting the tarball, digesting and yet knowing it'd be
> overwritten at the next sync is about where I got tired of the g-cpan
> method. I'm not about wanting to make ebuilds. :(

eh? g-cpan shouldn't be overwriting existing ebuilds, and portage will only do
it if its in the PORTDIR - or do you mean when you manually bump? (If so, ignore
the entire comment block ending....<HERE>)
> 
> > 
> > FWIW, I just built Maypole using g-cpan-0.15_rc3, no problem.
> > 
> 
> It wasn't a problem for me either, once I unmasked a bunch of modules. 
> 
> Would it be possible to do something like ACCEPT_KEYWORDS='~*' g-cpan blah
> and avoid having to stop and unmask the dev-perl/??? and then stop again to
> unmask the virtual/perl-???
> 
> Of course, that'd probably just be a problem next 'emerge world'. :(
> 
> > > CPAN might choke eventually on the dependencies for a package like 
> > > this, but gcpan... fails with less information... gcpan logging 
> > > doesn't get you much error info.
> > 
> > Again, wish you could give something more than "gcan just 
> > chokes." If I can't dup it and can't see what you mean, I 
> > can't hope to fix it :) I have worked pretty hard in the more 
> 
> I wasn't looking for a fix, but a workaround. I really don't expect a fix.
> ;-)
> 
> > recent versions of g-cpan to resolve these dependency issues 
> > better, so any examples you can give of where it's failing 
> > would help out a ton.
> 
> Well, rather than get into it, consider this, from the catalystframework
> overlay maintainer:
> 
> <quote http://forums.gentoo.org/viewtopic-t-419501-highlight-.html>
> There's no ebuild in portage for most of the modules, and g-cpan doesn't
> always behave well, This is particularly true when attempting the
> installation of the Task::Catalyst meta-module, which pulls in almost
> everything that is needed to write "serious" applications with Catalyst:
> since it uses CPANPLUS, problems come around.
> </quote>
> 
> So, I don't feel particularly off or unhelpful in saying 'it just chokes'.
> "Problems come around" or "doesn't always behave well" are also apt
> descriptions. 
> 
> Again, I was looking for a workaround, not a fix.

In that case, ping cab - I believe he's working with Michelle's overlay of
Catalyst to get it into portage.
 
 
> I thought this was a "user" list. I didn't file a bug, I was hoping someone
> out there using perl on gentoo (and maybe even reading the
> appropriately-named gentoo-perl mailing list) could help make a transition
> away from g-cpan.
> 
> My bad, I guess. :(
> 
> At this point, it seems the only way would be to put anything perlish in
> package.provided to keep portage from emerging perl modules. I may have to
> try that, barring some better advice.

I take requests for g-cpan :) Seriously, I feel like this email is degrading
rapidly, and will blame myself for being too defeneive the first time around.


> Ah, is this a gentoo-specific patch, then? I do find that whatever portage
> installed is preempting my CPAN installs. I imagine this is by design, but,
> how necessary is that, really?

When it was originally implemented, very. We were originally installing
everything to site, but were running into issues with core perl modules getting
sucked under and causing bad breakage. It's probably about time to re-examine
that patch (you're not the first to bring this up). Personally, at this point
I'd favor site_perl->vendor->core, so portage fills in above core, but what you
install manually overrides our ebuilds. Doesn't solve all of your problems, but
it would be a good step.

> I don't think you are being at all rude, especially if I was thinking of
> contributing as a developer, or was being critical of your work.
> 
> But, I'm a lowly user who'd like a solution to a problem that still exists.
> I don't feel qualified in any way to be a contributor. I think it's great
> that you're working on this stuff. Sometimes folks just want to install a
> module, or two, I suppose, and you've given them a nice tool for that.

Thank you :)
> 
<snip huge nice section that was worth reading>
> On another point, with all the CPAN testing going on, is there not some way
> to promote newer module versions automatically into portage? Why wouldn't a
> good score from CPANTS or CPAN Testers be enough for the x86 devs to fix up
> the ebuilds?
> 

eh, unfortunately not. Until all of CPAN is under a better qa watch, we still
have to do manual qa and file rt bugs like everyone else (and I have a score or
two open right now). While some modules are 'trustworthy' for bumping, not all
are.
 
 again, sorry for the huge delay in responding,

 ~mcummings

-- 

-----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-----o()o----------------------------------------------

Hi, I'm a .signature virus! Please copy me in your ~/.signature.

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

Re: [gentoo-perl] Big Perl Packages and g-cpan

[Michael Cummings]

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

FWIW, this is the Maypole-2.11 dependency tree that was generated by
g-cpan 0.15_rc3. Let me know if anything is glaringly missing:

DEPEND=">=perl-gcpan/Class-DBI-SQLite-0.11
        >=perl-gcpan/CGI-Untaint-1.26
        perl-gcpan/Class-DBI-Loader-Relationship
        perl-gcpan/Test-MockModule
        perl-gcpan/Class-DBI-Plugin-Type
        dev-perl/UNIVERSAL-moniker
        dev-perl/URI
        dev-perl/libwww-perl
        perl-gcpan/Class-DBI-AbstractSearch
        >=perl-gcpan/Class-DBI-Loader-0.32
        perl-gcpan/Class-DBI-Plugin-RetrieveAll
        dev-perl/Cgi-Simple
        perl-gcpan/Class-DBI-Pager
        dev-perl/HTML-Tree
        >=perl-gcpan/HTTP-Body-0.6
        >=dev-perl/Class-DBI-3.0.16
        dev-perl/Template-Toolkit
        perl-gcpan/Template-Plugin-Class
        >=perl-gcpan/File-MMagic-XS-0.08
        perl-gcpan/CGI-Untaint-date
        perl-gcpan/CGI-Untaint-email
        dev-perl/UNIVERSAL-require
        dev-lang/perl"

-- 

-----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-----o()o----------------------------------------------

Hi, I'm a .signature virus! Please copy me in your ~/.signature.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]