[Fedora-packaging] review cgilib issues

[Lucian Langa]

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