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.
