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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
