Re: RPM packaging and library versioning - Remi Collet - com.mysql.lists.plusplus

15 messages in com.mysql.lists.plusplusRe: RPM packaging and library versioning

From	Sent On	Attachments
Jack Eidsness	07 Mar 2007 15:20
Warren Young	07 Mar 2007 15:56
Remi Collet	08 Mar 2007 00:41
Warren Young	15 Mar 2007 16:57
Jack Eidsness	15 Mar 2007 23:21
Warren Young	16 Mar 2007 20:48
Remi Collet	18 Mar 2007 11:21
Warren Young	19 Mar 2007 05:48
Jack Eidsness	19 Mar 2007 08:04
Remi Collet	19 Mar 2007 11:12
Remi Collet	19 Mar 2007 11:58
Jack Eidsness	19 Mar 2007 12:25
Warren Young	19 Mar 2007 13:19
Warren Young	19 Mar 2007 13:22
Jack Eidsness	19 Mar 2007 15:39

Subject:	Re: RPM packaging and library versioning
From:	Remi Collet (Lis...@FamilleCollet.com)
Date:	03/19/2007 11:58:07 AM
List:	com.mysql.lists.plusplus

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

Remi.