[opensuse-packaging] How to do a library merge?
I'm trying to submit an upgrade of Firebird RDBMS to version 3.0 and I encountered an issue with other packages depending on its libraries, namely libreoffice. Firebird 2.5 provided two libraries with the same API: libfbclient and libfbembed. The libfbclient library allows to connect to a firebird server (local or remote) via TCP while libfbembed allows a direct access to a database stored in a local file (also called embedded server mode). LibreOffice and some other software use the "embedded server" library to store data in a local database file as a smarter alternative to e.g. sqlite. In openSUSE, we have three devel packages: firebird-devel (with common files, including all header files) libfbclient2-devel (libfbclient.so and fbclient.pc) and libfbembed-devel (libfbembed.so and fbembed.pc). With version 3.0, both access modes are now provided by a single library, libfbclient. I added Provides and Obsoletes for both libfbclient2-devel (the "2" was an old mistake) and libfbembed-devel but that doesn't really help. First, a package linking against -lfbembed won't be really satisfied by libfbclient-devel package. Second, this doesn't resolve build dependency on pkgconfig(fbembed) which libreoffice uses (and an explicit "Provides: pkgconfig(fbembed)" won't help even if it works). One idea is to provide a fbembed.pc file with Libs and Cflags copied from fbclient.pc so that any package using pkgconfig would still build. But that doesn't seem to be a clean solution. It would be nice if one could say "require either libfbclient-devel >= 3 or libfbembed-devel" but I don't think it's possible. Any other ideas? Or is it something that needs to be sorted out in packages depending on libfbembed? Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Mon, 16 May 2016, Michal Kubecek wrote:
With version 3.0, both access modes are now provided by a single library, libfbclient. I added Provides and Obsoletes for both libfbclient2-devel (the "2" was an old mistake) and libfbembed-devel but that doesn't really help. First, a package linking against -lfbembed won't be really satisfied by libfbclient-devel package. Second, this doesn't resolve build dependency on pkgconfig(fbembed) which libreoffice uses (and an explicit "Provides: pkgconfig(fbembed)" won't help even if it works).
One idea is to provide a fbembed.pc file with Libs and Cflags copied from fbclient.pc so that any package using pkgconfig would still build. But that doesn't seem to be a clean solution.
Well, if you don't want to change any depending packages, then you need to provide a fbembed.pc and an libfbembed.so file (the latter can be symlinked to libfbclient.so). If you do accept the idea of having to change depending packages then I wouldn't do any compatibility hacks in libfbclient, and just deal with the issues in those depending packages (are there many?)
It would be nice if one could say "require either libfbclient-devel >= 3 or libfbembed-devel" but I don't think it's possible.
Hackery based on %suse_version, as many other package do as well. But the make system of those package might need changes as well, not just the BuildRequires spec section; some might hardcode the -lfbembed name. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz
With version 3.0, both access modes are now provided by a single library, libfbclient. I added Provides and Obsoletes for both libfbclient2-devel (the "2" was an old mistake) and libfbembed-devel but that doesn't really help. First, a package linking against -lfbembed won't be really satisfied by libfbclient-devel package. Second, this doesn't resolve build dependency on pkgconfig(fbembed) which libreoffice uses (and an explicit "Provides: pkgconfig(fbembed)" won't help even if it works).
One idea is to provide a fbembed.pc file with Libs and Cflags copied from fbclient.pc so that any package using pkgconfig would still build. But that doesn't seem to be a clean solution.
Hello. Imho Firebird2 packages should be hold and Firebird3 ones should be provides additionally. At least shared object packages wouldn't provide any conflicts and everybody would have some time to port software to Firebird3. -- Best regards, Dmitriy Perlow R&D chemical engineer Lekpharm JLLC -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On úterý 17. května 2016 15:00 Michael Matz wrote:
If you do accept the idea of having to change depending packages then I wouldn't do any compatibility hacks in libfbclient, and just deal with the issues in those depending packages (are there many?)
Actually, right now, there is only one I know about (not counting php5 which hits a different problem, trivial to both fix and work around). Unfortunately this package is libreoffice so that I'm afraid I wouldn't get away with simply breaking it and calling it Someone Else's Problem.
Well, if you don't want to change any depending packages, then you need to provide a fbembed.pc and an libfbembed.so file (the latter can be symlinked to libfbclient.so).
That might work in general. However, as I found yesterday, even after fixing libreoffice's configure.ac, one of its unit tests fails so this trick wouldn't help either and working around the issue in firebird packages is out of question even as a short term workaround. Thanks for your help anyway. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michal Kubecek píše v Po 16. 05. 2016 v 14:48 +0200:
I'm trying to submit an upgrade of Firebird RDBMS to version 3.0 and I encountered an issue with other packages depending on its libraries, namely libreoffice.
Firebird 2.5 provided two libraries with the same API: libfbclient and libfbembed. The libfbclient library allows to connect to a firebird server (local or remote) via TCP while libfbembed allows a direct access to a database stored in a local file (also called embedded server mode). LibreOffice and some other software use the "embedded server" library to store data in a local database file as a smarter alternative to e.g. sqlite. In openSUSE, we have three devel packages: firebird-devel (with common files, including all header files) libfbclient2-devel (libfbclient.so and fbclient.pc) and libfbembed-devel (libfbembed.so and fbembed.pc).
With version 3.0, both access modes are now provided by a single library, libfbclient. I added Provides and Obsoletes for both libfbclient2-devel (the "2" was an old mistake) and libfbembed-devel but that doesn't really help. First, a package linking against -lfbembed won't be really satisfied by libfbclient-devel package. Second, this doesn't resolve build dependency on pkgconfig(fbembed) which libreoffice uses (and an explicit "Provides: pkgconfig(fbembed)" won't help even if it works).
One idea is to provide a fbembed.pc file with Libs and Cflags copied from fbclient.pc so that any package using pkgconfig would still build. But that doesn't seem to be a clean solution.
It would be nice if one could say "require either libfbclient-devel
= 3 or libfbembed-devel" but I don't think it's possible.
Any other ideas? Or is it something that needs to be sorted out in packages depending on libfbembed?
This is something that should be sorted out by the packages using libfbembed. Really you can do nasty stuff like symlink all the stuff and create new fake .pc file. But it would still work only in SUSE/openSUSE. What we should do is put new firebird to staging project and report bugs against all the packages that are failing and release firebird at the point it actually works with the stuff that we found. Cheers Tom
On úterý 17. května 2016 15:07 Tomas Chvatal wrote:
This is something that should be sorted out by the packages using libfbembed.
Really you can do nasty stuff like symlink all the stuff and create new fake .pc file. But it would still work only in SUSE/openSUSE.
What we should do is put new firebird to staging project and report bugs against all the packages that are failing and release firebird at the point it actually works with the stuff that we found.
Sounds like the best solution. Users who want to play with Firebird 3.0 and don't want to wait, can always get the packages in server:database (or snapshots in home:mkubecek:firebird30). Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Dmitriy Perlow -
Michael Matz -
Michal Kubecek -
Tomas Chvatal