NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
You can't ask the users anything... (Score:1)
> Test::More reveals test failures in DBI (which it does), the author of
> the dependent module (Andreas) can report a CPAN Version Advisory that
> DBI 1.59 and Test::More >= 0.71 are incompatible. When a user goes to
> install DBI the CPAN shell queries the service for any advisories. It
> uses that information to decide what to do. In this case it might say
> "DBI 1.59 is incompatible with your installed version of Tes
Re: (Score:1)
Of course, as with most things dependency-related, Debian got that right a long time ago, by tracking “reverse dependencies”, ie. not just what packages a package depends on, but also which packages it is a depeden
Re:You can't ask the users anything... (Score:1)
For example, our dependencies are complete (programatic in nature), vary across platforms and as such it's extremely difficult to know downstream deps.
That said, for any given host, you can "localize" the dependencies to static form, which could perhaps them be saved somehow...
The META.yml -> META-LOCAL.yml idea is looking better and better.
Reply to This
Parent
Re: (Score:1)
I don’t know what difference source vs binary would make in this case. The local inventory of installed software almost always differs from the repository, which generally only tracks information about the newest version of every package. So to use reverse dependency checks you always have to record them locally after each successful installation, anyway.
The CPAN client would have to determine the local final list of dependencies and then figure in the recorded reverse dependencies, and could then t