Problems with forked packages and CPAN

I'd like to upload a complex application (comprising several custom
modules and a daemon script) to my CPAN directory. I'm thwarted,
however, by the fact that its current distribution contains a couple of
forked packages from someone else's modules. This causes the CPAN
indexer to reject the whole distribution, since I don't own the package
namespaces declared by those files.

The forks fix small but fatal bugs in the modules they are part of,
which play a key role in my own application. I did contact the modules'
maintainer about the bugs via CPAN's RT, even supplying patch files,
but they never made the necessary updates to their own CPAN releases,
and I got tired of waiting.
(It's now been months.)

Is there a way I could have the indexer skip over my forks, or
something? It didn't have a problem with the rest of my distribution,
according to the email.

Re: Problems with forked packages and CPAN

zendonut@gmail.com writes:

> I did contact the modules' maintainer about the bugs via CPAN's RT,
> even supplying patch files, but they never made the necessary
> updates to their own CPAN releases, and I got tired of waiting.
> (It's now been months.)

CPAN's RT is quite new (compared to CPAN) and may not be read by
modules authors.

For each module rejected by the indexer, you should mention whether
the original author rejected the patch or simply did not respond.

For the former case, you'd need to fork and rename the module. But
that would be a really bad thing if you provide only bug fixes and not
major changes.

For the latter, we'd have to check if the module are really orphan and
find new maintainers (possibly you).

HTH

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

Re: Problems with forked packages and CPAN

[A complimentary Cc of this posting was sent to

], who wrote in article <1143744828.664098.60260@e56g2000cwe.googlegroups.com>:
> I'd like to upload a complex application (comprising several custom
> modules and a daemon script) to my CPAN directory. I'm thwarted,
> however, by the fact that its current distribution contains a couple of
> forked packages from someone else's modules. This causes the CPAN
> indexer to reject the whole distribution, since I don't own the package
> namespaces declared by those files.

I think you misunderstood the e-mail message from the indexer. Check
the indexer directly. It should mention the parts which are owned by
you.

When people use index for the modules you upgraded, they will be
directed to the "official" copies. However, *your* modules should
refer to your distributions nevertheless.

Hope this helps,
Ilya

Re: Problems with forked packages and CPAN

Dominique Dumont wrote:
> zendonut@gmail.com writes:
>
> > I did contact the modules' maintainer about the bugs via CPAN's RT,
> > even supplying patch files, but they never made the necessary
> > updates to their own CPAN releases, and I got tired of waiting.
> > (It's now been months.)
>
> CPAN's RT is quite new (compared to CPAN) and may not be read by
> modules authors.
>
> For each module rejected by the indexer, you should mention whether
> the original author rejected the patch or simply did not respond.

In this case the author acknowledged the patch and said that they'd get
around to a new release eventually, and then months passed with no
activity.

I suppose my next step involves appealing to the author in question
again, in light of the fact that they're now officially making things
difficult for new CPAN entries that wish to use their work. If nothing
comes of this I'll gripe back in this direction again.

Re: Problems with forked packages and CPAN

"jmac" writes:

> In this case the author acknowledged the patch and said that they'd get
> around to a new release eventually, and then months passed with no
> activity.

As a Perl module author, I sometimes forget about bug reports or
patches... Then, I appreciate a gentle nudge to get me going and
usually deliver a new release within a few days... :o)

Cheers

--
Dominique Dumont
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner