[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dependency issue with ocfs2-tools-pacemaker 1.6.3-1~bpo60+1



Good evening everyone,

thank you very much for bringing this up to my attention; it's been busy
weeks and I did not have the time to read all the various mailing lists
as it would have been appropriate.

Am 01.11.11 16:39, schrieb Cyril Brulebois:
> Hi all.
> 
> Axel Beckert <abe@debian.org> (01/11/2011):
>> Dinesh Pannu wrote on 13th of October 2011:
>>> The recent updates to pacemaker in backports have been causing me
>>> some grief. Having trouble installing ocfs2-tools-pacemaker which
>>> has a dependency conflict with pacemaker. pacemaker depends on
>>> libstonithd1 while ocfs2-tools-pacemaker depends on
>>> libstonithd0. libstonithd1 conflicts with libstonithd0.
>>
>> We ran into this issue, today, too.
> 
> Looks like a trivial problem to solve. Why are those libs in conflict
> exactly? The whole point of changing package names is that you can keep
> the old lib around until all packages are updated to use the new lib.
> Based on the contents of those files, I see no reasons why they would
> conflict. Except /u/s/d/$package, we have:
> 
Well, with Pacemaker, the situation is a little bit more difficult than
it might appear at the first look. libstonithd(-dev) along with all the
other libraries produced by the pacemaker source packages were originally
meant to be pacemaker helper libraries; i'm not even sure it was expec-
ted by somebody that other tools would be using them. 

libstonithd0 and libstonithd1 are conflicting with each other to force
libstonithd0 to be de-installed as soon as libstonithd1 is installed.

And that's the case because with Pacemaker 1.1.6 installed (the version
that brings libstonithd1 with it), running applications built against
Pacemaker 1.0 (the one with libstonithd0) is not only unsupported by
the Pacemaker upstream authors, but is also not going to work and might
cause more trouble cluster-wise than ocfs2_controld.pcmk not running at
all, making Pacemaker realize that something is wrong.

If you want Pacemaker 1.1.6, your applications will necessarily have to
use the libraries provided by that pacemaker version. Theoretically, it
would be possible to install libstonithd0 and libstonithd1 at the same
time. Practically, that makes no sense at all.

> libstonithd0_1.0.11-1~bpo60+1_amd64.deb:
>  /usr/lib/libstonithd.so.0.0.0
>  /usr/lib/libstonithd.so.0 -> libstonithd.so.0.0.0
> 
> libstonithd1_1.1.5-3~bpo60+1_amd64.deb:
>  /usr/lib/libstonithd.so.1.0.0
>  /usr/lib/libstonithd.so.1 -> libstonithd.so.1.0.0
> 
> Looks like a broken fix there:
> | pacemaker (1.1.5-3) unstable; urgency=low
> | 
> |   * debian/control: Really fix the issue with conflicting files this time,
> |     esp. for libstonithd1-dev vs. libstonithd0-dev (Closes: #639272)
> | 
> |  -- Martin Loschwitz <madkiss@debian.org>  Fri, 26 Aug 2011 13:09:40 +0000
> 
> Mraw,
> KiBi.

The -dev-packages of these libraries actually will have to conflict with 
each other as they contain files in /usr/lib with the same names, as the
bug report that you have just mentioned clearly suggests.

The correct solution for this problem is to rebuild ocfs2-tools with a
versioned build-dependency on the Pacemaker version in squeeze-backports.

I took the backports-packages and changed them accordingly. 

I'd be happy if somebody could test these packages on squeeze and tell 
me whether they work. If that's the case, I'll upload to squeeze-bp.

Best regards
Martin G. Loschwitz

--
Debian GNU/Linux Developer


Reply to: