1 |
On Wed, 03 Aug 2005 21:02:36 +0200 |
2 |
Michele Beltrame <admin@×××××××××.info> wrote: |
3 |
|
4 |
> > btw, the real issue here is that g-cpan is kinda dumb when it comes |
5 |
> > to packages that rename themselves (like /perl-tidy/i vs |
6 |
> > /perltidy/i) - i have thoughts on ways to correct this in the next |
7 |
> > version, always open |
8 |
> |
9 |
> Yep, the naming of module packages is a bit of a problem in |
10 |
> circumstances like this. By the way, how is this resolved in |
11 |
> situations such as LWP vs libwww-perl? |
12 |
> |
13 |
|
14 |
Lucky for me you chose a bad case example ;) LWP is bundled upstream in |
15 |
libwww-perl-*.tar.gz, so when the current g-cpan goes to resolve it, it |
16 |
sees libwww-perl and marks it as an existing dep. |
17 |
|
18 |
Some better examples would be: |
19 |
|
20 |
gtk2-fu (odd, since dams is both maintainer of the ebuild and author of |
21 |
the module) |
22 |
glib-perl |
23 |
XML-Sablot(ron) |
24 |
Parse-Yapp |
25 |
Locale-gettext |
26 |
CPAN-Mini-Phalanx |
27 |
Term-ANSIColor |
28 |
|
29 |
And all of this is of course something I didn't consider when we put out |
30 |
the last release of g-cpan. Plus (like there's not enough fun), it seems |
31 |
to be lacking in viable feedback on core installed modules versus |
32 |
needing an ebuild, IO::File being the best (and ok, pretty much only |
33 |
that I am aware of) example of that. |
34 |
|
35 |
And don't get me started on the whole PathTools thing... |
36 |
-- |
37 |
gentoo-perl@g.o mailing list |