Package: vim-gtk Version: 2:7.3.035+hg~8fdc12103333-1 User: debian-p...@lists.debian.org Usertags: perl-5.12-transition
When the vim Perl bindings were changed to dynamic loading, the packages stopped depending on libperl5.10. I can see that a hard dependency may not be wanted, but perhaps a recommendation or at least a suggestion would be in order? The lack of any dependency on libperl is going to be a problem when Perl is upgraded to a newer upstream version, in particular with the upcoming Perl 5.12 transition. The full name of the library ends up in the vim.gtk binary, so the Perl support stops working when the library changes to libperl5.12.3 (and it probably would with a hypothetical 5.10.2 too, for that matter, even if it was ABI compatible.) While binNMUing vim will fix this, the package dependencies will not indicate that in any way. This makes it rather easy for the release team to miss the binNMU requirement altogether and consequently makes it more difficult to keep track of the transition status. As dpkg-shlibdeps can not help here and I can't see an obviously clean and correct solution, perhaps it would be OK to cheat a bit and do something like Recommends: libperl5.10 Depends: perl-base (>= 5.10.1-17), perl-base (<< 5.10.2~) in a binNMU safe way? The alternatives I see are worse, such as Recommends: libperl5.10 Conflicts: libperl5.10 (<< 5.10.1-17), libperl5.10 (>= 5.10.2~), libperl5.12 which doesn't even work if we reach libperl5.14 for wheezy. OTOH, if we do allow a hard dependency on libperl it comes down to Depends: libperl5.10 (>= 5.10.1-17), libperl5.10 (<< 5.10.2~) which would probably be my preferred solution. Please let me know what you think. I can try to come up with a patch once I know your preference. I wonder if this applies to the other interpreters like Python too? -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
