| 1 |
g-cpan is not intended to be used (or rather, capable of being used) within |
| 2 |
an ebuild. g-cpan (which I don't think anyone will deny could use a |
| 3 |
refresh/rewrite) is for installing modules so that portage is aware of them |
| 4 |
without our needing to completely replicate cpan, which does a fine job as |
| 5 |
is. If you have an ebuild that depends on a perl module, that is grounds for |
| 6 |
the module being added to portage (insufficient grounds is "but i like this |
| 7 |
module" :) ) and you should include that when you submit the feature request |
| 8 |
for the ebuild (including an ebuild for the perl module will also go a long |
| 9 |
way with us grouchy perl folks). In the future you wil be able to do what |
| 10 |
you are describing, at least that is the goal, just not today :) |
| 11 |
|
| 12 |
-mike |
| 13 |
|
| 14 |
On Wed, Mar 10, 2004 at 11:50:55AM +0100, Andrej Kacian wrote: |
| 15 |
> Hi, is there any documentation about g-cpan.pl script? I was told it is the way |
| 16 |
> to pull in perl modules not handled by any ebuild, but am unsure as how to use |
| 17 |
> it. |
| 18 |
> |
| 19 |
> Suppose I have an application that needs perl module Foo::Bar-1.2.3, is it |
| 20 |
> sufficient to just put a line that says "g-cpan.pl Foo::Bar" somewhere in |
| 21 |
> pkg_preinst() ? |
| 22 |
> |
| 23 |
> -- |
| 24 |
> /~\ The ASCII Andrej "Ticho" Kacian <andrej at kacian dot sk> |
| 25 |
> \ / Ribbon Campaign GnuPG public key ID: 7CD93FE2 (pgp.mit.edu) |
| 26 |
> X Against HTML Key fingerprint: |
| 27 |
> / \ Email! E87D 9DEF 2A23 6FFB 7AD9 542F 4253 3A46 7CD9 3FE2 |
Archives