[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#692155: Please

Package: tech-ctte
Severity: normal

Hash: SHA1

I hereby ask the Technical Committee to resolve that:

1. As has already been done in the cups 1.5.3-4 package in experimental,
   cups in wheezy will depend on "libcups2 (= ${binary:Version})" instead
   of "libcups2 (>= ${binary:Version})".


libcups contains a public API as defined in it's public headers.
This public API behaves in terms of ABI stability as expected
from a public API.

Additionally, libcups contains an internal API not exposed through
it's public headers but used inside CUPS, not subject to any ABI

An example for ABI changes in the internal API caused problems for users
with the IPP backend updates between 1.5.2-7 and 1.5.2-8 that resulted
in the filing of bugs #668662 [1] and #677180 [2]. I also ran into this
problem, but didn't file a separate bug since #668662 was already open.

I suggested in #668662 "to have all cups package(s) that use these
internal functions in libcups2 depend on exactly the same version 
and Debian revision of libcups2 (e.g. Depends: libcups2 (= 1.5.3-1))". [3]

This was fixed by Martin Pitt in the upload of 1.5.3-2 to unstable [4]:
  * debian/control: Tighten cups' and cups-client's dependency to libcups2 to
    current binary version. They use private symbols from the libraries which
    the automatic dependencies from the .symbols files don't cover.
    (Closes: #668662, #677180)

Unfortunately this fix was incomplete with:
- - cups-client: Depends: libcups2 (= ${binary:Version})
- - cups: Depends: libcups2 (>= ${binary:Version})

I reopened the bug stating that the dependency of cups should also be
changed to "libcups2 (= ${binary:Version})" since "there is still the 
potential problem that a private symbol removed in a more recent 
libcups2 package causes breakage." [5] 

In the 1.5.3-4 upload to experimental Martin Pitt fixed this issue,
agreeing with my analysis in the changelog entry [6]:
  * debian/control: Have cups strictly depend on the same binary version of
    libcups2, to avoid crashes when later libcups2 versions remove private
    symbols. (Closes: #668662)

In unstable, for reasons unknown to me, the incomplete fix in 1.5.3-2 was
reverted in 1.5.3-2+wheezy0 [7], before it was re-applied in 1.5.3-2.4 [8].

The upload of 1.5.3-2.4 with the incomplete fix marked #668662
again as fixed, which I undid stating that "the fix in cups
is not complete" [9], also telling in the discussion that
"the package in experimental contains the correct fix." [10]

In the resulting discussion, Didier 'OdyX' Raboud stated [11] that
he "hereby, as NMUer and prospective maintainer, declare this bug
as fixed in the version in Wheezy" and urged me to "to seek other
opinions on the matter" (which I consider redundant considering
that Martin Pitt already agreed with me in the changelog of 1.5.3-4),
and to "bring this issue in front of the Technical Comittee if you
still don't agree", which I am hereby doing.

I am not aware of any technical downsides of having the dependency
strictly on exactly the same binary version, since problems with
binary NMUs or multiarch support caused by such strict dependencies
don't apply in such a case of the dependency of binaries on a shared

Thanks in advance for considering my request
Adrian Bunk

[1] http://bugs.debian.org/668662
[2] http://bugs.debian.org/677180
[3] http://bugs.debian.org/668662#32
[4] http://bugs.debian.org/668662#48
[5] http://bugs.debian.org/668662#58
[6] http://bugs.debian.org/668662#71
[7] http://anonscm.debian.org/gitweb/?p=pkg-cups/cups.git;a=commitdiff;h=988fb6034001c50cb3ee6f864c048f5a4a852b21
[8] http://bugs.debian.org/668662#86
[9] http://bugs.debian.org/668662#91
[11] http://bugs.debian.org/668662#105
[11] http://bugs.debian.org/668662#118

Version: GnuPG v1.4.12 (GNU/Linux)


Reply to: