List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:March 7 2007 11:56pm
Subject:Re: RPM packaging and library versioning
View as plain text  
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.
Thread
Re: RPM packaging and library versioningJack Eidsness8 Mar
  • Re: RPM packaging and library versioningWarren Young8 Mar
    • Re: RPM packaging and library versioningRemi Collet8 Mar
      • Re: RPM packaging and library versioningWarren Young16 Mar
        • Re: RPM packaging and library versioningJack Eidsness16 Mar
          • Re: RPM packaging and library versioningWarren Young17 Mar
            • Re: RPM packaging and library versioningRemi Collet18 Mar
              • Re: RPM packaging and library versioningWarren Young19 Mar
                • Re: RPM packaging and library versioningJack Eidsness19 Mar
                  • Re: RPM packaging and library versioningRemi Collet19 Mar
                    • Re: RPM packaging and library versioningJack Eidsness19 Mar
                  • Re: RPM packaging and library versioningWarren Young19 Mar
                    • Re: RPM packaging and library versioningJack Eidsness19 Mar
                • Re: RPM packaging and library versioningRemi Collet19 Mar
                  • Re: RPM packaging and library versioningWarren Young19 Mar