Bug#611573: vim: missing dependency on libperl

[Niko Tyni]

On Sun, Jan 30, 2011 at 06:01:08PM -0500, James Vega wrote:
> On Sun, Jan 30, 2011 at 2:26 PM, Niko Tyni <ntyni at debian.org> wrote:

> > 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.)
> 
> Hmm, would it make sense to try and change this so it only uses the name
> libperl5.10 instead of libperl5.10.1?

Yeah, I think that would help a bit. However, I expect we will have a
major Perl transition (5.10 -> 5.12 etc.) for every release in the future,
because upstream has switched to yearly non-ABI-compatible releases.

> > 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~)
> 
> Well, the intention of switching to dynamic loading of the language
> binding libraries was to allow people not to install them.  As such, I'd
> prefer not to require that users have to install related packages even
> if they choose not to install the language binding.

perl-base is Essential, that's why I chose it above :)
This doesn't generalize to other interpreters, though. And it's ugly.

> Maybe I could build a throwaway version of Vim with the language
> bindings built-in so dpkg-shlibdeps can do its detection and then use
> that information for the Recommends?  Would that be sufficient for
> whatever mechanism determines that packages should be binNMUed for
> library transitions pick up Vim?

Yes, that sounds workable. Partial upgrades can still get broken as
nothing makes sure the binNMU'd version gets pulled in along with the
new libperl and vice versa. That's probably not a showstopper though.

> I'd be interested in how other packages which do dynamic loading of
> libraries handle this situation.
> 
> > I wonder if this applies to the other interpreters like Python too?
> 
> I'd assume it applies to all of the bindings whenever they need a
> transition.  I'd be surprised if this is the first package to do dynamic
> loading and need binNMUs when the library it loads changes.  Maybe we
> can find precedent somewhere else?

Two packages I'm somewhat familiar with that do this are freeradius
and openldap.  They both dlopen() their own plugin shared objects first,
and these plugins are linked against the interpreter library.

They also don't make the libraries optional, but rather Depend on them.
This wastes disk space but not memory footprint. I expect it would be
possible to split the plugins to their own packages in case the disk
space was a problem.

The only package in the archive that Recommends: libperl5.10 is collectd,
which seems to also have a plugin in /usr/lib/collectd that's linked
against libperl. It takes no provisions for partial upgrades AFAICS.

This seems to suggest that the idea of a throwaway version linking against
the libraries would be the way to go, short of having intermediate dlopen'd
plugins like the others do.
-- 
Niko Tyni   ntyni at debian.org