[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-perl
Subject:    RE: [gentoo-perl] Big Perl Packages and g-cpan
From:       "Michael Higgins" <mhiggins () banfieldgroup ! com>
Date:       2007-02-21 21:38:04
Message-ID: 000c01c75600$9191f900$6564a8c0 () TBG ! local
[Download RAW message or body]

> -----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

[prev in list] [next in list] [prev in thread] [next in thread]