1 |
Leon, |
2 |
|
3 |
Agreed this should be over on dev (cc'd -user just so the thread |
4 |
watchers know). |
5 |
OK, so after sending that last message, I began thinking it |
6 |
through, and there are at least a few packages that might have perl |
7 |
module dependancies (doesn't some of the functionality of gimp require a |
8 |
few perl modules to be installed? pretty sure there is at least a few |
9 |
mainstream apps that have perl modules they need for some of their |
10 |
plugins...). |
11 |
If it were my call (ha! ok, everyone stop laughing, I know what |
12 |
that last line was worth) I'd recommend only maintaining those perl |
13 |
modules that actually are depended on, and even then discouraging the |
14 |
use of ebuilds for loading perl modules...er, not sure that made sense, |
15 |
second whack at it...keep around those modules that are needed for other |
16 |
ebuilds to succeed, but not try and replicate the cpan listings. For |
17 |
starters, modules get updated sporadically - there are some modules, |
18 |
still good, that haven't been touched in years because the developer was |
19 |
done with it. Others get updated a lot, and that could throw a wrench if |
20 |
you have apps depending on one version. |
21 |
|
22 |
My additional two cents (think I'm up to four now) is that perl |
23 |
modules are good to have in portage when they fulfill a dependancy, but |
24 |
personally I think it would be dangerous/risky to attempt to maintain an |
25 |
ebuild tree for perl modules. No offense to those who have made the |
26 |
ebuilds up to this point (seemant and danamark come to mind from a |
27 |
recent perusal, among others), but the whole point to the -MCPAN -e |
28 |
shell is that you are automatically filtering yourself into the mirror |
29 |
trees and aren't relying on the main cpan server to handle your request. |
30 |
|
31 |
Thinking of which - for apps that depend on perl modules, |
32 |
instead of building an ebuild for that module that points directly to |
33 |
the module on cpan, would it be possible to instead execute a one liner |
34 |
in perl that grabs and installs the module? ( perl -MCPAN -e install |
35 |
PERL::MODULE) |
36 |
|
37 |
Ok, time for more coffee, this thinking stuff hurts. |
38 |
|
39 |
Mike |
40 |
|
41 |
On Mon, Jul 08, 2002 at 01:03:42PM +0100, Leon Brocard wrote: |
42 |
> Michael Cummings sent the following bits through the ether: |
43 |
> |
44 |
> > Like I said, I'm a perl person to, and I'm not trying to rain on |
45 |
> > anyone's parade, but I think adding the full cpan list is both a |
46 |
> > reduplication of cpan's efforts and frankly little more than being able |
47 |
> > to say "I can emerge a module instead of just using perl's built in |
48 |
> > equivalent of an ebuild". |
49 |
> |
50 |
> I kinda agree. I've just submitted a bunch of Perl ebuilds and mostly |
51 |
> it's just a case of figuring out the right dependencies and putting |
52 |
> them in DEPEND. But sometimes, modules have an interactive install by |
53 |
> default and so I code up a src_compile to get around that. |
54 |
> |
55 |
> The problem (and I've been discussing this with London Perl Mongers |
56 |
> for the past week or so) is external dependencies, like XML::Parser |
57 |
> needing expat or XML::LibXML needing libxml. External library |
58 |
> dependencies aren't part of the Makefile.PL (this is a big problem |
59 |
> really). Thus I think it makes sense to have Perl module ebuilds (or |
60 |
> for a least some of the modules). I bet you most people actually use |
61 |
> less than 100 modules. It may be a good idea to have some of this |
62 |
> automated too. |
63 |
> |
64 |
> Leon |
65 |
> |
66 |
> ps should we move this to gentoo-dev? |
67 |
> -- |
68 |
> Leon Brocard.............................http://www.astray.com/ |
69 |
> Nanoware...............................http://www.nanoware.org/ |
70 |
> |
71 |
> ... Can you repeat the part after "Listen very carefully"? |
72 |
> _______________________________________________ |
73 |
> gentoo-user mailing list |
74 |
> gentoo-user@g.o |
75 |
> http://lists.gentoo.org/mailman/listinfo/gentoo-user |