[Debichem-devel] [Pkg-scicomp-devel] Open MPI 1.3 related rebuilds

[Adam C Powell IV]

On Sun, 2009-02-01 at 17:05 -0600, Steve M. Robbins wrote:
> On Sun, Feb 01, 2009 at 10:52:18AM -0600, Dirk Eddelbuettel wrote:
> > 
> > On 1 February 2009 at 00:37, Steve M. Robbins wrote:
> > | Hello Dirk,
> > | 
> > | On Mon, Jan 26, 2009 at 09:10:04PM -0600, Dirk Eddelbuettel wrote:
> > | 
> > | > Open MPI 1.3, released a few days ago, recommends a rebuild of its
> > | > dependencies.  
> > | > 
> > | > Given the fairly small number of affected packages, we are hoping do drive
> > | > this rebuild 'informally' rather than with the full force of libopenmpi-1.2
> > | > and libopenmpi-1.3 libraries (which would still require rebuilds, but also
> > | > delays via NEW etc pp).  Details and logs of this initiative are on a new
> > | > wiki page at   http://wiki.debian.org/OpenMPI13Transition
> > | 
> > | The wiki page states that Open MPI 1.3 is not binary compatible with
> > | Open MPI 1.2.  Presumably, therefore, the SONAME has changed.  
> > 
> > Not quite. It's more complicated because of the fact that at least three
> > different implementations (LAM/MPI, MPICH and MPICH2, OpenMPI) provide
> > /usr/lib/libmpi.so and there is no soname encoded.
> 
> That's not quite the case; the SONAME for the OpenMPI-supplied library
> is libmpi.so.0:
> 
> 	$ objdump -p /usr/lib/libmpi.so|grep SON
> 	  SONAME      libmpi.so.0
> 
> If a program linked against libmpi.so.0 fails to run with the new
> libmpi.so.0, then either there is a bug in OpenMPI 1.3 or the SONAME
> should change.  This is not confined to relinking dependent libraries
> in Debian packages: you will also break user-built code.
> 
> 
> > Also note that it isn't strictly incompatible. Some users of Open MPI that
> > were built agains 1.2.* continue to work under 1.3.
> 
> Sure, but the test for re-using an existing SONAME is
> 
> 	Is the ABI the same, or not?
> i.e.	Does *every* program continue to run, or not?
> 
> My understanding is that the answer is "no".

I have to agree with Steve.  We have versioned shlib package names for a
reason, though the second of these conditions (do old programs still
run) is more important than the first (has the ABI changed at all).

If you keep the same lib package name but can't provide continuity, it's
a bug.  It's not just a matter of best practices.  Debian policy is
pretty clear about this.  (It might even be an RC bug, though I'm not
sure and don't have the time to look into policy just now...)

If upstream doesn't change their soname, the new package should use
something like -1.3 in the shlib package name.

IIRC it's not a requirement that the old and new versions be
simultaneously installable or that the soname change (e.g. compiler ABI
changes don't require this), so feel free to leave the soname as
upstream has it.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20090203/b6855ee3/attachment.pgp