- Use author-independent source URL
- Drop support for building with Test::More < 0.88
- Specify all build dependencies
- Drop redundant buildroot cleaning in %install section
- Simplify find command using -delete
- Fix permissions verbosely
- Use %license where possible
None of currently supported distributions need that.
Last one was EL5 which is EOL for a while.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
None of currently supported distributions need that.
It was needed last for EL5 which is EOL now
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
- New upstream release 0.11
- Drop the dep on List::MoreUtils
(https://github.com/doy/dist-checkconflicts/pull/8)
- Update patch for building with Test::More < 0.88
- Don't try to run the extra tests for EPEL builds
- New upstream release 0.10
- We need Module::Runtime 0.009 for module_notional_filename (#6)
- Update patch for building with Test::More < 0.88
- Drop %defattr, redundant since rpm 4.4
- New upstream release 0.08
- Instead of silently ignoring conflicts that do not compile, issue a
conflict warning (CPAN RT#75486)
- BR: perl(Module::Runtime)
- Classify buildreqs by usage
- Explicitly run the extra tests
- New upstream release 0.06
- Add optional runtime conflict warnings
- Require 5.8.1, clean up a few things and add a few more tests
- Use Exporter instead of Sub::Exporter
- Update patch for building with Test::More < 0.88
- Drop patch for building with old ExtUtils::MakeMaker, no longer needed
- Don't need to remove empty directories from the buildroot
One shortcoming of the CPAN clients that currently exist is that they have no
way of specifying conflicting downstream dependencies of modules. This module
attempts to work around this issue by allowing you to specify conflicting
versions of modules separately, and deal with them after the module is done
installing.
For instance, say you have a module Foo, and some other module Bar uses Foo. If
Foo were to change its API in a non-backwards-compatible way, this would cause
Bar to break until it is updated to use the new API. Foo can't just depend on
the fixed version of Bar, because this will cause a circular dependency
(because Bar is already depending on Foo), and this doesn't express intent
properly anyway - Foo doesn't use Bar at all. The ideal solution would be for
there to be a way to specify conflicting versions of modules in a way that would
let CPAN clients update conflicting modules automatically after an existing
module is upgraded, but until that happens, this module will allow users to do
this manually.
