Bug#611573: vim: missing dependency on libperl

[Niko Tyni]

Package: vim-gtk
Version: 2:7.3.035+hg~8fdc12103333-1
User: debian-perl at 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   ntyni at debian.org