[DBIx-Class-Devel] Pull Request: topic/docs-pod-inherit

Brendan Byrd Perl at ResonatorSoft.org
Fri Dec 14 15:40:27 GMT 2012


On Fri, Dec 14, 2012 at 9:31 AM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
>
> POD separation works fine (at least on s.c.o. which is what *I* care
> about, metacpan can always catch up). It is the dual libdir that
> confuses it. I am waiting for 0.08204_02 to go through s.c.o.
> indexing[1], and if it looks fine I'll merge for_current/eumm_taming
> which contains all the trickery (in particular 374cd092).

Correct me if I'm wrong, but I can find absolutely nothing in META
that knows about the libdir structure.  So, it doesn't matter how or
where it's split up, as SCO/MetaCPAN will simply index anything that
isn't in no_index.  Thus, I can only think of a few ideas:

1. Separate .generated_pod/lib.  Already tried that.
2. Edit the PM directly.  Don't want to do that.
3. Combined directory with pod/pm together.  Doesn't change anything.
4. Kill the =NAME from the PM.  Still mods the PM, and may or may not
work, since SCO/MetaCPAN still tries to "interpret" the PM name.
5. Add the dupe PMs to no_index.  Might work, but not sure if this
causes adverse effects to CPAN, installs, and perldoc.

> Note this does *not yet* contain the $RUNNING_IN_HELL fixups to replace
> your s/'/"/ (which is very very un-unixy hence bad :) I ran out of tuits
> to wrap it up, but already identified the EUMM machinery which will make
> it happen.

Didn't Matt have a more elegant solution, back when I ran into this
issue many moons ago?

-- 
Brendan Byrd <Perl at ResonatorSoft.org>
Brendan Byrd <BBYRD at CPAN.org>



More information about the DBIx-Class-Devel mailing list