Hello,
I'm currently reviewing cgilib package (#450050). The same functionality is provided by a similar package already in fedora libcgi. I would initially suggest using Conflicts for cgilib as those two package will most obviously conflict. Mamoru was kind enough to detail this issues a little further:
* For these packages both packages the library named "libcgi.so.1", which is really a problem. - In this case a simple conflict method (like "Conflicts: libcgi" on cgilib") won't work as you desire, where there are some packages which Requires libcgi.so.1, because - An admin tries to install the package by "yum install foo" (where foo has the dependency for libcgi.so.1) - yum tries to resolve the dependency on foo, then finds that two packages have "Provides: libcgi.so.1". - Then yum will install either of libcgi or cgilib according to yum's implementation, i.e. we cannot expect which will actually be installed. However foo requires one of them, and perhaps foo won't work with the other one. - Here "Conflicts" does not work, because yum will try to install one of them, not both.
* Another problem is that the soname major version "1" on libcgi.so."1" in libcgi (in Fedora) was, actually, arbitrarily chosen by Fedora maintainer, not by the upstream. And unfortunately this decision now conflicts with cgilib. - You can check this from libcgi srpm, especially libcgi-1.0-Makefile.in.patch in libcgi.srpm. The original upstream tarball only creates libcgi.so with no soname, however the Fedora maintainer seems to have created a patch to add the proper soname to libcgi.so. Then the soname "libcgi.so.1" seems to have chosen. Actually on Debian (as far as I checked debian's libcgi) the soname is libcgi.so."0" (and here .0 was arbitrarily chosen by Debian's maintainer).
Any thoughts on this ?
Thank you, --lucian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Lucian Langa schrieb:
Hello,
I'm currently reviewing cgilib package (#450050). The same functionality is provided by a similar package already in fedora libcgi. I would initially suggest using Conflicts for cgilib as those two package will most obviously conflict. Mamoru was kind enough to detail this issues a little further:
I think you should renamed the created library into libcgilib.
Best Regards:
Jochen Schmitt
On Monday, 16 February 2009 at 20:57, Lucian Langa wrote:
Hello,
I'm currently reviewing cgilib package (#450050). The same functionality is provided by a similar package already in fedora libcgi. I would initially suggest using Conflicts for cgilib as those two package will most obviously conflict. Mamoru was kind enough to detail this issues a little further:
For these packages both packages the library named "libcgi.so.1", which is really a problem.
- In this case a simple conflict method (like "Conflicts: libcgi" on cgilib") won't work as you desire, where there are some packages which Requires libcgi.so.1, because
- An admin tries to install the package by "yum install foo" (where foo has the dependency for libcgi.so.1)
- yum tries to resolve the dependency on foo, then finds that two packages have "Provides: libcgi.so.1".
- Then yum will install either of libcgi or cgilib according to yum's implementation, i.e. we cannot expect which will actually be installed. However foo requires one of them, and perhaps foo won't work with the other one.
- Here "Conflicts" does not work, because yum will try to install one of them, not both.
Another problem is that the soname major version "1" on libcgi.so."1" in libcgi (in Fedora) was, actually, arbitrarily chosen by Fedora maintainer, not by the upstream. And unfortunately this decision now conflicts with cgilib.
- You can check this from libcgi srpm, especially libcgi-1.0-Makefile.in.patch in libcgi.srpm. The original upstream tarball only creates libcgi.so with no soname, however the Fedora maintainer seems to have created a patch to add the proper soname to libcgi.so. Then the soname "libcgi.so.1" seems to have chosen. Actually on Debian (as far as I checked debian's libcgi) the soname is libcgi.so."0" (and here .0 was arbitrarily chosen by Debian's maintainer).
Any thoughts on this ?
I think we cannot have two packages both providing a library with the same filename and soname while being incompatible (as in: not a drop-in replacement). One of them must be renamed.
Unrelated to this, libcgi maintainer should not have chosen to use libcgi.so.1 as the soname without upstream's approval.
Regards, R.
On Mon, 16 Feb 2009 21:16:46 +0100, Dominik wrote:
Unrelated to this, libcgi maintainer should not have chosen to use libcgi.so.1 as the soname without upstream's approval.
Not the first time this has happened. It's reviewer's responsibility to not approve such packages.
Current guidelines disallow static libs, reviewers point that out, packagers make up a soname and version, and reviewers accept it. Instead, they ought to reject such packages and request involvement of upstream developers in deciding on a soname and library versioning scheme.
"MS" == Michael Schwendt mschwendt@gmail.com writes:
MS> Current guidelines disallow static libs,
That is not true. They merely discourage it. "Package doesn't build as a dynamic library" is certainly sufficient justification.
MS> reviewers point that out, packagers make up a soname and version, MS> and reviewers accept it.
If they're going to make up a soname, they should at least start at 0. However, I don't see how the issue of inventing a soname is relevant here.
MS> Instead, they ought to reject such packages and request MS> involvement of upstream developers in deciding on a soname and MS> library versioning scheme.
Certainly we shouldn't be going to steps to turn static libraries into dynamic ones without at least trying to talk to upstream about the issue. We shouldn't be making _any_ significant alterations to any packaged software without trying to talk to upstream.
- J<
On Mon, 16 Feb 2009 17:17:41 -0600, Jason wrote:
"MS" == Michael Schwendt writes:
MS> Current guidelines disallow static libs,
That is not true. They merely discourage it. "Package doesn't build as a dynamic library" is certainly sufficient justification.
The current wording,
| Static libraries should only be included in exceptional circumstances.
is strong enough to make some packagers add patches for creating a shared lib.
MS> reviewers point that out, packagers make up a soname and version, MS> and reviewers accept it.
If they're going to make up a soname, they should at least start at 0. However, I don't see how the issue of inventing a soname is relevant here.
It's relevant in that it doesn't matter how we [Fedora Package Collection] differ from upstream and other distributions. Sometimes we differ in SONAME, e.g. %{version} as part of the SONAME, sometimes we only differ in the major library version. Preferably we don't differ in such fundamental details.
It becomes worse if upstream finally decides to [re]start at .0 after packagers have had a higher version already.
Starting at .0 makes sense, and usually that is done, but for interfaces which are not stable, the package maintainer either needs to bump the version accordingly or still rebuild all dependencies for lib updates and hidden ABI/API breakage.
MS> Instead, they ought to reject such packages and request MS> involvement of upstream developers in deciding on a soname and MS> library versioning scheme.
Certainly we shouldn't be going to steps to turn static libraries into dynamic ones without at least trying to talk to upstream about the issue. We shouldn't be making _any_ significant alterations to any packaged software without trying to talk to upstream.
Library Makefiles are being changed, however, and although reviewers should notice it while examining the Patch files, nobody re-reviews changes applied in cvs. There are more questionable alterations to upstream installation defaults (not just in the Fedora pkg collection, e.g. add pkg-config templates), but they are beyond the scope of this reply.
In general, though, we don't want to create -devel packages to be used by software developers running Fedora, that lead to software releases which are incompatible with non-Fedora installations.
packaging@lists.fedoraproject.org
-
Dominik 'Rathann' Mierzejewski -
Jason L Tibbitts III -
Jochen Schmitt -
Lucian Langa -
Michael Schwendt