1 |
Yuval Yaari wrote: |
2 |
> |
3 |
> Isn't there a more elegant way than preventing pod being converted to |
4 |
> man pages? |
5 |
> I personally don't `man` my modules, so I won't suffer from it, but |
6 |
> maybe someone out there does? (otherwise, why is pod2man even being |
7 |
> invoked?). |
8 |
> |
9 |
> Just my $.02... |
10 |
> |
11 |
> --Yuval |
12 |
|
13 |
I'm open to suggestions on elegance - this was just the best I could |
14 |
come up with. The collision happens when a user installs a module that |
15 |
is also provided by the perl core. Since we toss everything into vendor |
16 |
(and then reverse the @inc so it wins the elections) the modules |
17 |
themselves never conflict - just the man3 pages. Personally, I've never |
18 |
man'd something I could perldoc (fwiw, this wouldn't affect the core |
19 |
perl docs, just those provided by add on ebuilds). As near as I can |
20 |
grok, pod2man is automatically invoked if INSTALLMAN3DIRS has a value - |
21 |
except you can't unset it in the perl install, or it will install of the |
22 |
perl core docs to / (believe you me, that was fun)(unless it was before |
23 |
I had the amazing ='none' syntax down right...in which case we might be |
24 |
able to avoid all of the man3 jazz). |
25 |
|
26 |
Some other thoughts on the subject were to find a new, non man3 home for |
27 |
these man pages (leaving the core man3 pages where they are), or...well, |
28 |
I had this thought about utilizing the ebuilds we have for upgrading |
29 |
core perl modules, but that was even more convoluted and painful in the |
30 |
long run (@10 minutes after you finished installing perl, the pain would |
31 |
begin). |
32 |
|
33 |
No worries, my fingers aren't even near a commit button :) (otherwise I |
34 |
wouldn't have posted it on here) |
35 |
|
36 |
~mike |
37 |
-- |
38 |
gentoo-perl@g.o mailing list |