| Subject: | Versions being seperate from Module versions results in dependency confusion |
At present, there appears to be no module shipped in this distribution where the shipped module contains a version matching the version of the distribution, and this leads to a very confusing and misleading effect.
The most recent version as stated by any module shipped in this distribution, and Perl 5.14.0 Ships with some version of "1.08", but what exactly this means is uncertain.
If somebody depends on 1.37, their dependency will be unsatisfiable, and if somebody depends on 1.08, what version they'll end up getting is uncertain....
At least from an outside perspective, Although it will probably get them the right module, a cursory glance at what their perl -M line spits out and what is listed in corelist, will confuse people when they look up the same distribution on CPAN and think "Why hasn't this been updated in core since 1995!?! ".
Although it *has* been updated, the module which is being dependend on in most places is still 1.08, and people tend to assume that the "primary" module for a distribution should match that distributions version.
Granted, from the code end of the system, Perl itself may not have an issue with how this is being done, but its still confusing to us mortals who are trying to do checks and things while adding new versions of things to our Linux Distribution trees.
If you are averse to aligning either ::Util::Call or ::Util::Exec 's version with the distributions, another approach some take that you may like is the addition of a stub package for dependency purposes, ie: package Filter::VERSION; our $version = 1.37; > Filter/VERSION.pm , then people can depend on Filter::VERSION 1.37 and know what they're getting, and clarify what is going on.
Hope this bug report is found to be useful =).
The most recent version as stated by any module shipped in this distribution, and Perl 5.14.0 Ships with some version of "1.08", but what exactly this means is uncertain.
If somebody depends on 1.37, their dependency will be unsatisfiable, and if somebody depends on 1.08, what version they'll end up getting is uncertain....
At least from an outside perspective, Although it will probably get them the right module, a cursory glance at what their perl -M line spits out and what is listed in corelist, will confuse people when they look up the same distribution on CPAN and think "Why hasn't this been updated in core since 1995!?! ".
Although it *has* been updated, the module which is being dependend on in most places is still 1.08, and people tend to assume that the "primary" module for a distribution should match that distributions version.
Granted, from the code end of the system, Perl itself may not have an issue with how this is being done, but its still confusing to us mortals who are trying to do checks and things while adding new versions of things to our Linux Distribution trees.
If you are averse to aligning either ::Util::Call or ::Util::Exec 's version with the distributions, another approach some take that you may like is the addition of a stub package for dependency purposes, ie: package Filter::VERSION; our $version = 1.37; > Filter/VERSION.pm , then people can depend on Filter::VERSION 1.37 and know what they're getting, and clarify what is going on.
Hope this bug report is found to be useful =).