| 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 |
Archives