Thanks so much! this makes perfect sense to me now.
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
> # rpm -q --whatprovides 'libmysqlclient.so.15()(64bit)'
> 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
> 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
> # rpm -ql mysqlclient14 | grep lib64
> 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