Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • > What happens is when there's a dependency problem, say a bug fix in
    > 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
    • So they agree to a downgrade (which doesn’t REALLY know how to do properly anyway, except by installing over the top of the newer version) and now they have an older version of a module which breaks a dependency of something ELSE which needed the new version to work.

      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

      • Debian is an excellent binary repository, but it is most certainly NOT a great model if you have a source repository.

        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.
        • 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 tell you whether any unresolvable conflicts exist and hash out a resolution for the other conflicts automatically.

          Of course, the CPAN client does not actually keep any inventory of the locally installed stuff at all, let alone recording reverse dependencies, so deploying all this will take a fair amount of new infrastructure in the toolchain and quite a long period of incubation until we can rely on it. (But it would not require ubiquity before attaining usefulness, so it’s a realistic goal.)