1 |
> -----Original Message----- |
2 |
> From: Michael Cummings [mailto:mcummings@g.o] |
3 |
> |
4 |
> On Wed, 21 Feb 2007 13:38:04 -0800 |
5 |
> "Michael Higgins" <mhiggins@×××××××××××××.com> wrote: |
6 |
> |
7 |
> > > -----Original Message----- |
8 |
> <snip> |
9 |
> > ... which is what I had to do just to get started. Why are so many |
10 |
> > modules out of date? Why do I need virtuals in here? B/C |
11 |
> otherwise the |
12 |
> > keyword unmasking fails. |
13 |
> |
14 |
> Because the x86 team hasn't unmasked any of these. Other arch's have, |
15 |
> x86 is just behind on these. I know sparc and amd64 are |
16 |
> pretty up to date, and even alpha stays pretty close to the |
17 |
> curve, x86 is just slow. |
18 |
> I think they prefer to have stable ticket requests to mark |
19 |
> something, but with 666 modules (roughly) that's more hand |
20 |
> holding than I think we're up to. |
21 |
|
22 |
Hmm. So, it's incumbent on the user to unmask all potentially-used |
23 |
ebuild-available modules? Or, when a module is released to CPAN, maybe a |
24 |
ticket request needs to go automatically to the x86 folks? |
25 |
|
26 |
Anyway, to try and fix the issues (and I don't care how, g-cpan -ned or |
27 |
-less is fine), I've just scripted a bunch of additions to package.keywords |
28 |
from eix reports of perl modules in portage, hopefully thereby unmasking |
29 |
anything that might come up as a dependency and is already in portage. |
30 |
|
31 |
Now, if I can find a way to loop around g-cpan, simply automatically |
32 |
unmasking anything it chokes on and making it try again... |
33 |
|
34 |
Would you take a 'feature request' for that functionality? After all, they |
35 |
are just perl modules. |
36 |
|
37 |
And, what do I do when a module comes up in portage, but the latest masked |
38 |
version is still not satisfying the dependencies? |
39 |
|
40 |
Editing an ebuild, wgetting the tarball, digesting and yet knowing it'd be |
41 |
overwritten at the next sync is about where I got tired of the g-cpan |
42 |
method. I'm not about wanting to make ebuilds. :( |
43 |
|
44 |
> |
45 |
> FWIW, I just built Maypole using g-cpan-0.15_rc3, no problem. |
46 |
> |
47 |
|
48 |
It wasn't a problem for me either, once I unmasked a bunch of modules. |
49 |
|
50 |
Would it be possible to do something like ACCEPT_KEYWORDS='~*' g-cpan blah |
51 |
and avoid having to stop and unmask the dev-perl/??? and then stop again to |
52 |
unmask the virtual/perl-??? |
53 |
|
54 |
Of course, that'd probably just be a problem next 'emerge world'. :( |
55 |
|
56 |
> > CPAN might choke eventually on the dependencies for a package like |
57 |
> > this, but gcpan... fails with less information... gcpan logging |
58 |
> > doesn't get you much error info. |
59 |
> |
60 |
> Again, wish you could give something more than "gcan just |
61 |
> chokes." If I can't dup it and can't see what you mean, I |
62 |
> can't hope to fix it :) I have worked pretty hard in the more |
63 |
|
64 |
I wasn't looking for a fix, but a workaround. I really don't expect a fix. |
65 |
;-) |
66 |
|
67 |
> recent versions of g-cpan to resolve these dependency issues |
68 |
> better, so any examples you can give of where it's failing |
69 |
> would help out a ton. |
70 |
|
71 |
Well, rather than get into it, consider this, from the catalystframework |
72 |
overlay maintainer: |
73 |
|
74 |
<quote http://forums.gentoo.org/viewtopic-t-419501-highlight-.html> |
75 |
There's no ebuild in portage for most of the modules, and g-cpan doesn't |
76 |
always behave well, This is particularly true when attempting the |
77 |
installation of the Task::Catalyst meta-module, which pulls in almost |
78 |
everything that is needed to write "serious" applications with Catalyst: |
79 |
since it uses CPANPLUS, problems come around. |
80 |
</quote> |
81 |
|
82 |
So, I don't feel particularly off or unhelpful in saying 'it just chokes'. |
83 |
"Problems come around" or "doesn't always behave well" are also apt |
84 |
descriptions. |
85 |
|
86 |
Again, I was looking for a workaround, not a fix. |
87 |
|
88 |
> |
89 |
> > |
90 |
> > gcpan's CPAN is way out of date too... I have to wonder, why? |
91 |
> > |
92 |
> |
93 |
> Because you never upgraded it...? ;) Seriously, we don't push |
94 |
> CPAN as an ebuild because its not a dep of anything directly, |
95 |
> and you can always g-cpan to bootstrap it to a newer version. |
96 |
> |
97 |
|
98 |
I never thought to do that. I assumed (reasonably, I think) g-cpan to be |
99 |
some kind of a front-end to CPAN and, as such, should of course use the |
100 |
latest version that it's, well, "front-ending". |
101 |
|
102 |
But I never looked 'under the hood' and don't expect to. |
103 |
|
104 |
> > Anyway, I'm just trying to figure out the best route for managing |
105 |
> > these installations. CPAN is fine for me, as long as I don't... |
106 |
> > what... emerge any modules? |
107 |
> |
108 |
> |
109 |
> Not sure what you're asking. If you don't want to use g-cpan, |
110 |
|
111 |
Asking how to maintain a gentoo/portage system with up-to-date perl modules |
112 |
added via CPAN, but still able to, say, install mod_perl so that it works |
113 |
the 'gentoo way' but doesn't clobber my up-to-date CPAN-installed modules. |
114 |
|
115 |
> don't, that's pretty simple. g-cpan is for those folks that |
116 |
> want some modules, but want them in the pretty portage |
117 |
> architecture. if your more comfortable using cpan, use cpan. |
118 |
|
119 |
It's not that simple. If you emerge anything dependent on any perl module, |
120 |
portage will install it and CPAN will choke on the out-of-date modules |
121 |
portage installed, with infinite loops, no "upgrade" option.... aargh. |
122 |
|
123 |
> Just don't file bugs about it with us :) (duh, I know, but |
124 |
> you'd be amazed)(or not) |
125 |
|
126 |
I thought this was a "user" list. I didn't file a bug, I was hoping someone |
127 |
out there using perl on gentoo (and maybe even reading the |
128 |
appropriately-named gentoo-perl mailing list) could help make a transition |
129 |
away from g-cpan. |
130 |
|
131 |
My bad, I guess. :( |
132 |
|
133 |
At this point, it seems the only way would be to put anything perlish in |
134 |
package.provided to keep portage from emerging perl modules. I may have to |
135 |
try that, barring some better advice. |
136 |
|
137 |
> > |
138 |
> > It seemed to me at one point that it might be better, |
139 |
> somehow, to just |
140 |
> > find a way to patch CPAN to check and emerge any modules in the |
141 |
> > portage tree... expect they are often out of date anyway. :( |
142 |
> > |
143 |
> |
144 |
> emerge how? cpan isn't about working with a package manager, |
145 |
> any package manager. |
146 |
|
147 |
That'd be the 'patch' part. ;-) Specific to portage users...?? |
148 |
|
149 |
> |
150 |
> > If one does move away from gcpan, I think one will need to unmerge |
151 |
> > stuff from the tree and the overlay. At least, I've been |
152 |
> bitten once |
153 |
> > so far. I suppose they install in different locations? (No time to |
154 |
> > check.) |
155 |
> > |
156 |
> |
157 |
> by default, cpan installs in site. we install in vendor. the |
158 |
> reverse inc patch |
159 |
|
160 |
Ah, is this a gentoo-specific patch, then? I do find that whatever portage |
161 |
installed is preempting my CPAN installs. I imagine this is by design, but, |
162 |
how necessary is that, really? |
163 |
|
164 |
> puts vendor at the top of the food chain, |
165 |
> followed by site. |
166 |
> So yes, anything you install by ebuild will trump a cpan install. |
167 |
> |
168 |
> > Gosh, I wish I had more time to devote to this now. I'll |
169 |
> look forward |
170 |
> > to your reply. |
171 |
> |
172 |
> You shouldn't - i'm tired and crabby and writing when i |
173 |
> should be sleeping, which means i'm being a lot more rude |
174 |
> than intended. |
175 |
> |
176 |
|
177 |
I don't think you are being at all rude, especially if I was thinking of |
178 |
contributing as a developer, or was being critical of your work. |
179 |
|
180 |
But, I'm a lowly user who'd like a solution to a problem that still exists. |
181 |
I don't feel qualified in any way to be a contributor. I think it's great |
182 |
that you're working on this stuff. Sometimes folks just want to install a |
183 |
module, or two, I suppose, and you've given them a nice tool for that. |
184 |
|
185 |
. . . |
186 |
|
187 |
Given what you've written, it would seem that removing the reverse @INC |
188 |
patch would solve the problem as well, no? Portage could install whatever it |
189 |
wanted, but my CPAN-installed module would be found first, right? |
190 |
|
191 |
Is this something I can tweak easily? Would doing that then allow me to use |
192 |
CPAN and not have portage install older modules that are then found first in |
193 |
@INC? |
194 |
|
195 |
Anyway, the upshot is that I still don't have a working, easily replicable |
196 |
installation of some perl-based application frameworks. It seems the |
197 |
solution for, for example the catalystframework folk, was to make an ebuild. |
198 |
And put up a starter list of modules to unmask. |
199 |
|
200 |
I'm trying to go the g-cpan route again, should I find I need to install any |
201 |
missing modules, just to see if there's any improvement in the process now |
202 |
that I've unmasked everything I can find in the portage tree. |
203 |
|
204 |
Anyway, I hope you don't find my attempt at exacting language to be terse to |
205 |
the point of rudeness. I am glad for your feedback so far and would love to |
206 |
arrive at a solution. |
207 |
|
208 |
I've been working on a development server, but my production server I'll be |
209 |
working up soon. It'd just be nice to know that I can replicate an |
210 |
installation with several perlish development frameworks comprised of |
211 |
hundreds of perl modules without any hassle as described above. I don't care |
212 |
what the workaround is. |
213 |
|
214 |
On another point, with all the CPAN testing going on, is there not some way |
215 |
to promote newer module versions automatically into portage? Why wouldn't a |
216 |
good score from CPANTS or CPAN Testers be enough for the x86 devs to fix up |
217 |
the ebuilds? |
218 |
|
219 |
Cheers, |
220 |
|
221 |
-- |
222 |
Michael Higgins |
223 |
IS Specialist |
224 |
The Banfield Group |
225 |
Phone: (503) 352-3380 x205 |
226 |
Fax: (503) 352-3389 |
227 |
E-mail: mhiggins@×××××××××××××.com |
228 |
|
229 |
|
230 |
-- |
231 |
gentoo-perl@g.o mailing list |