List:MySQL++« Previous MessageNext Message »
From:Jack Eidsness Date:March 19 2007 7:25pm
Subject:Re: RPM packaging and library versioning
View as plain text  
Thanks so much! this makes perfect sense to me now.

-Jack Eidsness

Remi Collet wrote:
> Jack Eidsness a écrit :
>> This should go in the repository instead of an RPM-based patch, probably
>> to go out as a 2.2.2.  
> 
> Of course. It's just a try a do some tests.
> I'm not going to push this RPM. Waiting for 2.2.2.
> 
>> The so_version isn't really there to fix the RPM,
>> it fixes the forwards compatibility of having multiple library versions
>> installed.  That's how I was looking at it - I wanted more predictable
>> behavior through package management when I started this thread, but this
>> doesn't help with that.  "My way" would be to have only one version of
>> the lib, and consequently, the so_version stuff would be mostly
>> irrelevant, assuming you have the ability to rebuild whatever you've
>> been linking to mysql++.
> 
> I don't think so.
> If you build from source, you have the ability to rebuild.
> If you use RPM, you don't.
> 
> RPM Dependencies are handle on the .so.# lib :
> 
>    # rpm -q --requires php-mysql | grep libmysql
>    libmysqlclient.so.15()(64bit)
>    libmysqlclient.so.15(libmysqlclient_15)(64bit)
>    # rpm -q --whatprovides 'libmysqlclient.so.15()(64bit)'
>    mysql-5.0.37-1.fc6.remi
> 
> When updating the lib (.so.#) it will break the dependency.
> 2 solutions :
> 	- compat-* is available and will be install during the update
> 	- compat-* not available, no update
> In this way, nothing is broken.
> 
> This is a very predictable behavior, use by must of the distro.
> 
> Updating .so.#.#.# is not a problem because it is ABI compatible.
> 
>> I don't think that's what people expect for a package and it's "-devel"
>> counterpart.  the .so and the .so.v.v.v serve essentially the same
>> purpose, 
> 
> Don"t think.
> .so.#  is used at run time (try ldd on a binary).
> .so    is used at build time only.
> 
>> and if there needed to be a "-devel" package, it would have
>> header files in /usr/include.  
> 
> Of course -devel also have the header files.
> Most server installations doesn't need -devel stuff.
> It's even a security need to remove all the building stuff (gcc...)
> 
>> I don't think it's worthwhile to split
>> them out.
>>   I haven't made time to find a decent example, but I have a vague
>> memory of some packages having a "-compat" counterpart, that
>> simultaneously meets my package management expectations and allows
>> multiple library versions to coexist. 
> 
> Yes, compat-* or some other name.
> 
> For example :
>    # rpm -ql compat-libf2c-34
>    /usr/lib64/libg2c.so.0
>    /usr/lib64/libg2c.so.0.0.0
>    # rpm -ql mysqlclient14 | grep lib64
>    /usr/lib64/mysql/libmysqlclient.so.14
>    /usr/lib64/mysql/libmysqlclient.so.14.0.0
>    /usr/lib64/mysql/libmysqlclient_r.so.14
>    /usr/lib64/mysql/libmysqlclient_r.so.14.0.0
> 
> Usually, when an ABI change occurs on the distro, all other
> packages requiring the lib are rebuild.
> compat-* RPM is provided when this is not possible.
> 
>> I would expect that "just
>> mysql++.*.rpm" would have the includes (why not?) as well as the library
>> in .so.v.v.v and with a .so symlink, and if you wanted to simultaneously
>> have a mysql++.1.7*.rpm, you could install it as a mysql++-compat-1.7
> 
> Using the split solution, you can install mysql++-1.7 and mysql-2.2.1
> as there is no file conflicts.
> 
> You can only install one -devel.
> 
> 
>> package, and that would just have a .so.4.0.0 and no symbolic link, and
>> no .h files, or headers in some non-standard directory (not sure about
>> this last part).
>>
>> -Jack Eidsness
>>
> 
> Remi.
> 
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