Gentoo Archives: gentoo-perl

From: Michael Higgins <mhiggins@×××××××××××××.com>
To: gentoo-perl@l.g.o
Subject: RE: [gentoo-perl] Big Perl Packages and g-cpan
Date: Wed, 21 Feb 2007 21:37:48
Message-Id: 000c01c75600$9191f900$6564a8c0@TBG.local
In Reply to: Re: [gentoo-perl] Big Perl Packages and g-cpan by Michael Cummings
> -----Original Message----- > From: Michael Cummings [mailto:mcummings@g.o] > > On Mon, 19 Feb 2007 14:16:22 -0800 > "Michael Higgins" <mhiggins@×××××××××××××.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 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@g.o mailing list


Subject Author
Re: [gentoo-perl] Big Perl Packages and g-cpan Michael Cummings <mcummings@g.o>
Re: [gentoo-perl] Big Perl Packages and g-cpan Michael Cummings <mcummings@g.o>