On Sun Jan 06 13:08:49 2019, RATCLIFFE wrote:
Show quoted text> Hi Phil,
>
> On 02/01/2019 15:49, Phil M. Perry via RT wrote:
> > I still can't find any information about whether "recommends" lists
> > me in your Reverse dependencies, which is what I'm looking for.
>
> When do you expect this to happen?
>
> Reverse dependencies can only normally be calculated by a package
> manager, as they can be very volatile. There is
>
>
https://metacpan.org/pod/CPAN::ReverseDependencies
As a courtesy to optional library authors (like you), I'd like to be listed in your library's Reverse dependencies as a user of your library. That's primarily what I'm looking for with this whole issue. It doesn't hurt that it also provides some advertising for me.
Show quoted text>
> If you are looking for the Graphics::TIFF page on CPAN or metaCPAN to
> mention PDF::Builder, then I can add that manually to the POD.
You may, if you wish to, but package authors (me) shouldn't have to go around asking optional library authors (you) to manually update their PODs. There should be some way to handle this automatically and that it show up in the CPAN listings.
Show quoted text>
> > It sounds like it will suggest to the user during installation that
> > they install Graphics::TIFF (or other optional libraries), which I
> > don't want to do. People will tend to automatically agree to install
> > other stuff, and if GT fails (say, due to lack of libtiff.a), I fear
> > they will blow off PDF::Builder at that point. I'd rather they make
> > a cool, rational decision to install GT based upon their needs, and
> > not blindly click "yes" during install.
>
> Surely this is exactly what you want, and why you want "recommends"
> and not "requires", as Graphics::TIFF failing to build due to a
> missing libtiff should not fail the PDF::Builder install.
I have two concerns: 1) a failing Graphics::TIFF install looks bad, even if PDF::Builder still succeeds (naive users might not trust it), and 2) adding Graphics::TIFF would bloat their Perl library installation even if they never use TIFF images. As I said, I'd rather they make a cool, rational decision, after thinking it over, than automatically concur with an additional installation they don't really need.
Show quoted text>
> Why don't you give it a go? Set up a Build.PL for Module::Build with
> recommends, remove libtiff and Graphics::TIFF and see what happens.
That's a possibility. At least I can see if it actually tries to install Graphics::TIFF (with or without permission). I'm not going to spend the time on this, though, until I know whether PDF::Builder would definitely show up in the Reverse dependencies.
Show quoted text>
> > My starting point right now is Makefile.PL, hand-updated as
> > necessary. I may have to consider going to MakeMaker or Build.PL
> > (further up the food chain) if that's what it takes to be able to
> > use "recommends". I'm looking at the DBD::AnyData package (as an
> > example), which has both a Build.PL and a Makefile.PL, but only the
> > Build.PL features "recommends". I'm not sure if Makefile.PL was
> > built from Build.PL, or by hand, and the author forgot the
> > "recommends" entry.
>
> Makefile.PL is MakeMaker. AFAIK, Makefile.PL/MakeMaker do not support
> recommends.
That's disappointing that I would have to shift to Build.PL. I'll consider it if I can get the desired results from "recommends", or there are other considerations.
Show quoted text>
> > Maybe it's time to try to contact the CPAN staff and see what they
> > know about this.
I did, but haven't heard anything back yet.
Show quoted text>
> And/or maybe the authors of MakeMaker and Module::Build.
>
> Regards
>
> Jeff
Thanks for the information and suggestions. Perhaps I'll try playing with Build.PL some day when I have some free time, and switch over to it (from the hand-coded Makefile.PL) if it gives the desired results.
By the way, per our old discussion, did you ever make any headway on building libtiff.a from C during Graphics::TIFF install? Installations compile/link C code all the time, but I don't know how a ".a" library archive would fit in to this.
