1 |
I know, I'm doing such a great job of responding in a timely fashion :) |
2 |
|
3 |
On Wed, Mar 14, 2007 at 02:47:26PM -0700, Michael Higgins wrote: |
4 |
|
5 |
> Hmm. So, it's incumbent on the user to unmask all potentially-used |
6 |
> ebuild-available modules? Or, when a module is released to CPAN, maybe a |
7 |
> ticket request needs to go automatically to the x86 folks? |
8 |
|
9 |
No, it is not incumbent. Since this thread started (I know, there's only been a |
10 |
few posts to it, but that still counts), I've worked with the x86 folks to bring |
11 |
the keywords up to date for that platform. As a general rule, barring security |
12 |
fixes and the like, something should be in the tree for 30-60 days before a |
13 |
request to mark it stable can be filed. That said, I (and my fellow perl devs) |
14 |
aren't perfect - its perfectly feasible and likely that we will miss modules |
15 |
that are worthy of marking stable on your $arch (human volunteers and all that). |
16 |
You are always welcome, as a user of Gentoo, to submit a bug requesting that |
17 |
something go stable - if nothing else its a warm fuzzy that people are out there |
18 |
and using stuff and actually in need of it (vs our guessing that folks are |
19 |
trying stuff). |
20 |
|
21 |
> |
22 |
> Anyway, to try and fix the issues (and I don't care how, g-cpan -ned or |
23 |
> -less is fine), I've just scripted a bunch of additions to package.keywords |
24 |
> from eix reports of perl modules in portage, hopefully thereby unmasking |
25 |
> anything that might come up as a dependency and is already in portage. |
26 |
> |
27 |
> Now, if I can find a way to loop around g-cpan, simply automatically |
28 |
> unmasking anything it chokes on and making it try again... |
29 |
> |
30 |
|
31 |
Believe me, this is a feature I have in mind for 0.16 (0.15 is too far out the |
32 |
door for this kind of addition). My frame of thought is comparing your |
33 |
ACCEPT_KEYWORD against the needed ebuild's KEYWORDS and making a copy in your |
34 |
overlay if necessary. That and actually documenting this disparity between |
35 |
what's keyworded in the tree and what g-cpan's keyworded.... |
36 |
|
37 |
> Would you take a 'feature request' for that functionality? After all, they |
38 |
> are just perl modules. |
39 |
|
40 |
um, done :) |
41 |
|
42 |
|
43 |
> And, what do I do when a module comes up in portage, but the latest masked |
44 |
> version is still not satisfying the dependencies? |
45 |
|
46 |
gripe at us :) those automated emails that get sent are to remind us of what's |
47 |
getting behind in the tree. We try to tackle them as often as possible - but |
48 |
other things crop up (i'm done giving excuses, don't worry) |
49 |
|
50 |
> Editing an ebuild, wgetting the tarball, digesting and yet knowing it'd be |
51 |
> overwritten at the next sync is about where I got tired of the g-cpan |
52 |
> method. I'm not about wanting to make ebuilds. :( |
53 |
|
54 |
eh? g-cpan shouldn't be overwriting existing ebuilds, and portage will only do |
55 |
it if its in the PORTDIR - or do you mean when you manually bump? (If so, ignore |
56 |
the entire comment block ending....<HERE>) |
57 |
> |
58 |
> > |
59 |
> > FWIW, I just built Maypole using g-cpan-0.15_rc3, no problem. |
60 |
> > |
61 |
> |
62 |
> It wasn't a problem for me either, once I unmasked a bunch of modules. |
63 |
> |
64 |
> Would it be possible to do something like ACCEPT_KEYWORDS='~*' g-cpan blah |
65 |
> and avoid having to stop and unmask the dev-perl/??? and then stop again to |
66 |
> unmask the virtual/perl-??? |
67 |
> |
68 |
> Of course, that'd probably just be a problem next 'emerge world'. :( |
69 |
> |
70 |
> > > CPAN might choke eventually on the dependencies for a package like |
71 |
> > > this, but gcpan... fails with less information... gcpan logging |
72 |
> > > doesn't get you much error info. |
73 |
> > |
74 |
> > Again, wish you could give something more than "gcan just |
75 |
> > chokes." If I can't dup it and can't see what you mean, I |
76 |
> > can't hope to fix it :) I have worked pretty hard in the more |
77 |
> |
78 |
> I wasn't looking for a fix, but a workaround. I really don't expect a fix. |
79 |
> ;-) |
80 |
> |
81 |
> > recent versions of g-cpan to resolve these dependency issues |
82 |
> > better, so any examples you can give of where it's failing |
83 |
> > would help out a ton. |
84 |
> |
85 |
> Well, rather than get into it, consider this, from the catalystframework |
86 |
> overlay maintainer: |
87 |
> |
88 |
> <quote http://forums.gentoo.org/viewtopic-t-419501-highlight-.html> |
89 |
> There's no ebuild in portage for most of the modules, and g-cpan doesn't |
90 |
> always behave well, This is particularly true when attempting the |
91 |
> installation of the Task::Catalyst meta-module, which pulls in almost |
92 |
> everything that is needed to write "serious" applications with Catalyst: |
93 |
> since it uses CPANPLUS, problems come around. |
94 |
> </quote> |
95 |
> |
96 |
> So, I don't feel particularly off or unhelpful in saying 'it just chokes'. |
97 |
> "Problems come around" or "doesn't always behave well" are also apt |
98 |
> descriptions. |
99 |
> |
100 |
> Again, I was looking for a workaround, not a fix. |
101 |
|
102 |
In that case, ping cab - I believe he's working with Michelle's overlay of |
103 |
Catalyst to get it into portage. |
104 |
|
105 |
|
106 |
> I thought this was a "user" list. I didn't file a bug, I was hoping someone |
107 |
> out there using perl on gentoo (and maybe even reading the |
108 |
> appropriately-named gentoo-perl mailing list) could help make a transition |
109 |
> away from g-cpan. |
110 |
> |
111 |
> My bad, I guess. :( |
112 |
> |
113 |
> At this point, it seems the only way would be to put anything perlish in |
114 |
> package.provided to keep portage from emerging perl modules. I may have to |
115 |
> try that, barring some better advice. |
116 |
|
117 |
I take requests for g-cpan :) Seriously, I feel like this email is degrading |
118 |
rapidly, and will blame myself for being too defeneive the first time around. |
119 |
|
120 |
|
121 |
> Ah, is this a gentoo-specific patch, then? I do find that whatever portage |
122 |
> installed is preempting my CPAN installs. I imagine this is by design, but, |
123 |
> how necessary is that, really? |
124 |
|
125 |
When it was originally implemented, very. We were originally installing |
126 |
everything to site, but were running into issues with core perl modules getting |
127 |
sucked under and causing bad breakage. It's probably about time to re-examine |
128 |
that patch (you're not the first to bring this up). Personally, at this point |
129 |
I'd favor site_perl->vendor->core, so portage fills in above core, but what you |
130 |
install manually overrides our ebuilds. Doesn't solve all of your problems, but |
131 |
it would be a good step. |
132 |
|
133 |
> I don't think you are being at all rude, especially if I was thinking of |
134 |
> contributing as a developer, or was being critical of your work. |
135 |
> |
136 |
> But, I'm a lowly user who'd like a solution to a problem that still exists. |
137 |
> I don't feel qualified in any way to be a contributor. I think it's great |
138 |
> that you're working on this stuff. Sometimes folks just want to install a |
139 |
> module, or two, I suppose, and you've given them a nice tool for that. |
140 |
|
141 |
Thank you :) |
142 |
> |
143 |
<snip huge nice section that was worth reading> |
144 |
> On another point, with all the CPAN testing going on, is there not some way |
145 |
> to promote newer module versions automatically into portage? Why wouldn't a |
146 |
> good score from CPANTS or CPAN Testers be enough for the x86 devs to fix up |
147 |
> the ebuilds? |
148 |
> |
149 |
|
150 |
eh, unfortunately not. Until all of CPAN is under a better qa watch, we still |
151 |
have to do manual qa and file rt bugs like everyone else (and I have a score or |
152 |
two open right now). While some modules are 'trustworthy' for bumping, not all |
153 |
are. |
154 |
|
155 |
again, sorry for the huge delay in responding, |
156 |
|
157 |
~mcummings |
158 |
|
159 |
-- |
160 |
|
161 |
-----o()o---------------------------------------------- |
162 |
Michael Cummings | #gentoo-dev, #gentoo-perl |
163 |
Gentoo Perl Dev | on irc.freenode.net |
164 |
Gentoo/SPARC |
165 |
Gentoo/AMD64 |
166 |
GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E |
167 |
-----o()o---------------------------------------------- |
168 |
|
169 |
Hi, I'm a .signature virus! Please copy me in your ~/.signature. |