Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
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 Test::More (0.71).
    > Would you like to downgrade to 0.70?" It could even get clever and note that
    > a given module is only a build requirement and temporarily downgrade just
    > for the build and tests.

    "Would you like to downgrade?"

    It's going to be extremely difficult for users in this situation. If we apply the "7 layers of recursion" principle, how are they going to have any idea what to do in this situation?

    Most likely they'll not know, but your question suggests they probably should.

    So they agree to a downgrade (which CPAN.pm 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.

    I see lots of places where this could go wrong...

    Perhaps an alternative would be to flag the new Test::More version as "pathological", which would (temporarily) remove it from the index.

    This would let you "back out" a buggy (either itself, or downstream) released version, with the index reverting to an older version.

    You'd get a window to fix the downstream modules, and then you could enable that release again...

    • It's going to be extremely difficult for users in this situation. If we apply the "7 layers of recursion" principle, how are they going to have any idea what to do in this situation?

      It provides the user with *some* information and a way out, as opposed to nothing. Part of the point is just to make this sort of ad-hoc information that we normally communicate via word-of-mouth available to the world in a human and machine readable format.

      But I see your point. Yes, the downgrading may be problematic, but i

      • > It requires the author's intervention. Often the very problem is that an
        > author is not being responsive. It does not address the bottleneck issue.
        > You could just have the CPAN cabal unilaterally decide to yank a module from
        > the index, but this is not a happy making thing, CPAN has always been very
        > hands off, and it just moves the bottleneck to the CPAN cabal. The advisories
        > allow either end of the relationship to report the problem.

        As I understand it, in your description it's the CP
        • My mistake, that should have said "Tim". Fixed that.

          To clarify, the people issuing the advisories are the authors of the modules effected. The author on either side of the relationship can issue the advisory, so in my Test::More / DBI example it's either me or Tim Bunce.

          It's also possible that a 2nd or 3rd order dependent could issue an advisory. So, say, Matt Trout could issue the Test::More / DBI advisory because DBIx::Class needs DBI and his users are effected by the breakage.

          There would also be trust
    • So they agree to a downgrade (which CPAN.pm 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 t