From: Warren Young
Date: March 7 2007 11:56pm
Subject: Re: RPM packaging and library versioning
List-Archive: http://lists.mysql.com/plusplus/6419
Message-Id: <45EF5143.8040901@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jack Eidsness wrote:
> 1) installing two different versions did not create a conflict; this 
> could be considered handy, if you had some reason to link to two 
> different versions of the library, but I think that's kind of far 
> fetched.

This was done on purpose.  You need multiple versions of the library 
installed when you have binaries linked against one version of the 
library, then upgrade the library, then build more binaries without 
updating the old ones.  This happens frequently outside the pure open 
source world.

A patch to change this will be rejected, with prejudice.

> More likely, it gave us some difficult-to-detect bugs, but I'm not
> completely sure.

I could see that happening if you install an older version of the 
library alongside a newer one, in that order.  Then, the old library 
blasts the new one's .so symlink, which is probably not what you wanted. 
  The solution to this is better management of the symlink.

> 2) doing rpm -Uvh new.i386.rpm ... deleted the symbolic link without 
> recreating it.  honestly, that seems like a bug, to me, in the upgrade 
> process to run %postun for the old version before doing %post for the 
> new one.

I agree.  This one I'll happily accept patches for.  I just hadn't 
gotten around to fixing it myself.

In light of my guess at the source of your problems above, such a patch 
should probably be smart enough to realize when the symlink already 
exists and points to a newer version of the library.  In that case, it 
shouldn't disturb it.  Otherwise, it adds it regardless of whether it 
existed already or not.

> What do you think is wrong with writing a patch for the Makefile (i 
> presume to add -soname to the gcc options)?

The problem is that we don't use Makefiles, directly.  They're all 
generated from mysql++.bkl, by the Bakefile tool.  Since the purpose of 
using Bakefile is to abstract away platform differences, it would have 
to be an awfully special patch for me to accept it.

I would be much happier if you detected the availability of this option 
in the autoconf stage.  See the thread library detection stuff for ideas 
of how to accomplish this.