Le 28/11/2015 22:38, James McCoy a écrit :
> On Sun, Nov 29, 2015 at 08:24:15AM +1100, Craig Small wrote:
>> I've been helping someone with a vim plugin called vim-command-t[1] and
>> we've both hit a snag. The problem is that when I used pbuilder it
>> linked the plugin to libruby 2.2 but my vim is linked to libruby2.1
>
> Your vim is outdated, then. Vim was rebuilt over 2 weeks ago as part of
> the Ruby 2.2 transition. The only time there should be a discrepancy is
> in the middle of a transition.
>
>> Now, the package has in its dependencies libruby2.2. libruby2.2 and
>> libruby2.1 are both installed. As far as dpkg is concerned, all is well.
>>
>> Is there some way of putting some dependency onto vim to say "I want
>> the vim linked to libruby2.2". One idea is to figure out what version
>> they did link to it and put that in, but that's hard to maintain and
>> doesn't work across architectures nicely.
>>
>> Generically the problem is:
>> binary foo linked to libbar1, control file pulls in libbar1
>> plugin baz linked to libbar2, control file pulls in libbar2
>>
>> But when foo tries to load plugin baz, it fails. Is it a problem with
>> the plugin? Should it be using "ruby things" via the binary?
>
> No, it's just normal turbulence during a transition. I don't think
> there's anything in particular that needs to be done.
I cannot find a vim plugin linked to libruby2.[12] in the archive.
So, for now, nothing is done, indeed.
But, once such a plugin will exist, something will have to be
done on ruby transitions, to ensure that partial upgrades work.
Generally, this involves setting up manual Breaks lines in new
packages when the transition occurs and/or defining virtual packages
(such as vim-api-libruby2.2) that plugins depends on (automatically or
not).
The goal is to ensure that is will not be possible for a user to
upgrade only the plugin or only the core with partial upgrades.
I really suffer from the R transition that did not fix the partial
upgrade scenario between wheezy and jessie (see #710289). I really
think that such scenario must be correctly handled by maintainers,
either manually if transitions are rare and do not affect to many
packages or with automated helpers.
And, for the new plugin (vim-command-t), either a minimal version
should be added to the vim dependency or a Breaks on older vim version
must be added. This would ensure that partial upgrades (vim from
jessie and vim-command-t from testing) will be forbidden by APT.
Not that the situation can be more tricky here as there exists several
vim packages (ie I did not know if depending on a particular vim version
will ensure that the package containing the binary linked to libruby2.X
(ie vim-gnome, ...) will be at the same version)
Regards,
Vincent
> Cheers,
--
Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
