Warren Young wrote:
> Remi Collet wrote:
>
>> Patch0: mysql++-2.2.1-bkl.patch
>
> What is this patch? Should I apply it to the repository?
This should go in the repository instead of an RPM-based patch, probably
to go out as a 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++.
Remi Collet wrote:
> You only have to change
> %files
> %{_libdir}/libmysqlpp.so.*
> ...
>
> %files devel
> %{_libdir}/libmysqlpp.so
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, and if there needed to be a "-devel" package, it would have
header files in /usr/include. 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. 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
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
