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.
>
