Hi all,
is there any good way how to handle the situation described at
https://bugzilla.redhat.com/show_bug.cgi?id=528524
?
I.e. you have a single library (single soname) which can be compiled with or without GUI support (with different ABI) -- and we'd like to have both of them, of course -- the non-GUI version on headless servers, the GUI one for desktop.
As far "yelling at upstream" sounds like the most correct way.
Thanks in advance for any advice, Milos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/17/2010 09:04 AM, Milos Jakubicek wrote:
Hi all,
is there any good way how to handle the situation described at
https://bugzilla.redhat.com/show_bug.cgi?id=528524
?
I.e. you have a single library (single soname) which can be compiled with or without GUI support (with different ABI) -- and we'd like to have both of them, of course -- the non-GUI version on headless servers, the GUI one for desktop.
As far "yelling at upstream" sounds like the most correct way.
Thanks in advance for any advice, Milos
This is not a properly-built library. You can't have the same SONAME and different ABI. That's the entire point of a SONAME. The proper way would be to build the library always with GUI support and then not USE the GUI portions of the ABI unless you need to.
If they also have different API, I strongly recommend yelling at upstream.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On 18.1.2010 13:17, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/17/2010 09:04 AM, Milos Jakubicek wrote:
Hi all,
is there any good way how to handle the situation described at
https://bugzilla.redhat.com/show_bug.cgi?id=528524
?
I.e. you have a single library (single soname) which can be compiled with or without GUI support (with different ABI) -- and we'd like to have both of them, of course -- the non-GUI version on headless servers, the GUI one for desktop.
As far "yelling at upstream" sounds like the most correct way.
Thanks in advance for any advice, Milos
This is not a properly-built library. You can't have the same SONAME and different ABI. That's the entire point of a SONAME.
I know.
The proper way would
be to build the library always with GUI support and then not USE the GUI portions of the ABI unless you need to.
This is currently the case -- the library is of course built with GUI support, but that means that the package depends on whole a lot of stuff ending with X11 libraries which is not desirable on a headless server.
I was thinking about whether there would be a more or less correct way to build the libraray twice (with and without GUI) into two subpackages with mutual Provides/Obsoletes (allowing to install the non-GUI version by default and possibly substitute with the GUI one on demand). But this stinks indeed (not only because of the sonames)...and one would have to ensure that all the dependencies will behave good.
I was just curious whether there are not another packages with similar problems and possible solutions to look at in Fedora.
Regards, Milos
Hello Milos,
Monday, January 18, 2010, 2:27:22 PM, you wrote:
is there any good way how to handle the situation described at
https://bugzilla.redhat.com/show_bug.cgi?id=528524
?
I.e. you have a single library (single soname) which can be compiled with or without GUI support (with different ABI) -- and we'd like to have both of them, of course -- the non-GUI version on headless servers, the GUI one for desktop.
As far "yelling at upstream" sounds like the most correct way.
I'd suggest that the proper solution would be to separate the GUI functions into a separate library with a separate-but-related soname, and have that library depend on the non-GUI library.
That way the final GUI tools would depend on both libraries, and the equivalent command line tools only on the non-GUI library.
If possible, common functions should use shared code hosted in the non-GUI library. Otherwise you could get different results from the slightly different code in the two libraries. These lead to "it works if I do it by A1, but fails with A2" bug reports.
From this user's POW, it gets more insane if A1 and A2 are the same tool that supports running in GUI and command line modes.
Al