Consider giving libemon.so a real soname when building a shared library

[amluto]

Hi-

I'm playing with packaging lemon for Fedora. Currently everything works (as long as I don't try to link against glpk), but the resulting libemon.so doesn't have an associated version. This will cause issues when lemon gets upgraded.

Would you be willing to version it for real or at least to create libemon-1.3.so and symlink it to libemon.so? (The latter is a bit annoying in that it will force all users to rebuild for each new major release, but it's better than causing silent failures.)

Thanks!

[Alpar Juttner]

Thanks for the effort for Fedora packaging, should it get into public repository, please let us know either here or on the mailing list.

To be honest, I can't see any advantage of providing a shared library instead of a static one. The vast majority of LEMON is implemented as templates, the library (libemon.a/libemon.so) is very tiny. The benefit of sharing it among processes is really negligible.

[amluto]

The coin-or-lemon package is now in updates-testing for Fedora 19 and 20.

Fedora policy says that everything should be a shared library. Even for something like lemon, there's a good reason: when lemon 1.4 comes and and I update the Fedora package, everything using lemon should be rebuilt. If there's a shared library with a real soname, then bumping the soname version will be enough to get all the version dependencies right and to tell me what needs to be rebuilt.

I'm currently patching lemon like this:

sover_prefix="SET_TARGET_PROPERTIES(lemon PROPERTIES OUTPUT_NAME emon"
grep -q "${sover_prefix})" lemon/CMakeLists.txt
sed -i -e "s/${sover_prefix})/${sover_prefix} VERSION %{libemon_soversion} SOVERSION %{libemon_soversion})/" lemon/CMakeLists.txt

where %{libemon_soversion} is '0.1'.

If upstream lemon did something as simple as making the soversion equal to the version of lemon, then this would happen for free, and people linking against lemon shared libraries wouldn't have to worry about silent breakage if their libemon.so stopped matching the things built against it. (And different versions could be installed in parallel.)

[Alpar Juttner]

Replying to amluto:

Could you please confirm that this patch​ is what you need?

On the other hand, wouldn't it be possible/useful to include both the static and the shared version of the lib into the package?

[amluto]

Replying to alpar:

Replying to amluto:

Could you please confirm that this patch​ is what you need?

Yes, exactly. I probably won't push it out to Fedora 19 and 20 until Lemon 1.4 is released to avoid unnecessary recompilation, though.

On the other hand, wouldn't it be possible/useful to include both the static and the shared version of the lib into the package?

I could do that. Technically, I'd create an optional -static subpackage to supply the .a file. I'd probably only do that if there were demand. No Fedora packages would use it, but Fedora users could certainly use it.

--Andy

[Alpar Juttner]

This fix is in branches default and 1.3 as [9153e490f09c]. So, it will be included in the upcoming bugfix release 1.3.1.