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

[Jochen Schmitt]

-----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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmZyMEACgkQT2AHK6txfgzKpACfbt6SAX4llRDVoFEsBndg45yz
> t7AAnRSHBXEyuPUdTLWxrc9r4WtTOvGV
> =6b7s
> -----END PGP SIGNATURE-----

[Dominik 'Rathann' Mierzejewski]

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.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Michael Schwendt]

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.

[Jason L Tibbitts III]

> >>>> "MS" == Michael Schwendt
> <mschwendt(a)gmail.com&gt; 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<

[Michael Schwendt]

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.