1 |
On Wed, 21 Feb 2007 13:38:04 -0800 |
2 |
"Michael Higgins" <mhiggins@×××××××××××××.com> wrote: |
3 |
|
4 |
> > -----Original Message----- |
5 |
<snip> |
6 |
> ... which is what I had to do just to get started. Why are so many |
7 |
> modules out of date? Why do I need virtuals in here? B/C otherwise |
8 |
> the keyword unmasking fails. |
9 |
|
10 |
Because the x86 team hasn't unmasked any of these. Other arch's have, |
11 |
x86 is just behind on these. I know sparc and amd64 are pretty up to |
12 |
date, and even alpha stays pretty close to the curve, x86 is just slow. |
13 |
I think they prefer to have stable ticket requests to mark something, |
14 |
but with 666 modules (roughly) that's more hand holding than I think |
15 |
we're up to. |
16 |
|
17 |
FWIW, I just built Maypole using g-cpan-0.15_rc3, no problem. |
18 |
|
19 |
> CPAN might choke eventually on the dependencies for a package like |
20 |
> this, but gcpan... fails with less information... gcpan logging |
21 |
> doesn't get you much error info. |
22 |
|
23 |
Again, wish you could give something more than "gcan just chokes." If I |
24 |
can't dup it and can't see what you mean, I can't hope to fix it :) I |
25 |
have worked pretty hard in the more recent versions of g-cpan to |
26 |
resolve these dependency issues better, so any examples you can give of |
27 |
where it's failing would help out a ton. |
28 |
|
29 |
> |
30 |
> gcpan's CPAN is way out of date too... I have to wonder, why? |
31 |
> |
32 |
|
33 |
Because you never upgraded it...? ;) Seriously, we don't push CPAN as |
34 |
an ebuild because its not a dep of anything directly, and you can |
35 |
always g-cpan to bootstrap it to a newer version. |
36 |
|
37 |
> Anyway, I'm just trying to figure out the best route for managing |
38 |
> these installations. CPAN is fine for me, as long as I don't... |
39 |
> what... emerge any modules? |
40 |
|
41 |
|
42 |
Not sure what you're asking. If you don't want to use g-cpan, don't, |
43 |
that's pretty simple. g-cpan is for those folks that want some modules, |
44 |
but want them in the pretty portage architecture. if your more |
45 |
comfortable using cpan, use cpan. Just don't file bugs about it with |
46 |
us :) (duh, I know, but you'd be amazed)(or not) |
47 |
> |
48 |
> It seemed to me at one point that it might be better, somehow, to |
49 |
> just find a way to patch CPAN to check and emerge any modules in the |
50 |
> portage tree... expect they are often out of date anyway. :( |
51 |
> |
52 |
|
53 |
emerge how? cpan isn't about working with a package manager, any |
54 |
package manager. |
55 |
|
56 |
> If one does move away from gcpan, I think one will need to unmerge |
57 |
> stuff from the tree and the overlay. At least, I've been bitten once |
58 |
> so far. I suppose they install in different locations? (No time to |
59 |
> check.) |
60 |
> |
61 |
|
62 |
by default, cpan installs in site. we install in vendor. the reverse |
63 |
inc patch puts vendor at the top of the food chain, followed by site. |
64 |
So yes, anything you install by ebuild will trump a cpan install. |
65 |
|
66 |
> Gosh, I wish I had more time to devote to this now. I'll look forward |
67 |
> to your reply. |
68 |
|
69 |
You shouldn't - i'm tired and crabby and writing when i should be |
70 |
sleeping, which means i'm being a lot more rude than intended. |
71 |
|
72 |
~mcummings |
73 |
|
74 |
-- |
75 |
|
76 |
-----o()o---------------------------------------------- |
77 |
Michael Cummings | #gentoo-dev, #gentoo-perl |
78 |
Gentoo Perl Dev | on irc.freenode.net |
79 |
Gentoo/SPARC |
80 |
Gentoo/AMD64 |
81 |
GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E |
82 |
-----o()o---------------------------------------------- |
83 |
|
84 |
Hi, I'm a .signature virus! Please copy me in your ~/.signature. |