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

Bug#692155: marked as done (Dependency of cups on libcups2 in wheezy)

Your message dated Sat, 3 Nov 2012 01:47:28 +0200
with message-id <20121102234728.GE12410@bunk.dyndns.info>
and subject line Re: Bug#692155: Please
has caused the Debian Bug report #692155,
regarding Dependency of cups on libcups2 in wheezy
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

692155: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692155
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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)


--- End Message ---
--- Begin Message ---
On Fri, Nov 02, 2012 at 11:30:07PM +0100, Didier 'OdyX' Raboud wrote:
> Hi dear CTTE members, hi Adrian,

Hi Didier,

> Considering:
> d) that no-one has reported an actual bug revealed by the weak dependency in
>    the 1.5.3-2.4 version;
> e) that I still think that the way #668662 was fixed in 1.5.3-2.4 will not let
>    actual bugs slip through (because there are no new features planned in
>    wheezy, and I don't expect security fixes to alter the internal symbols
>    list);

One scenario is that someone running wheezy cherry-picks an application 
from unstable, jessie or backports that pulls through its' dependencies 
a more recent libcups2 that has a symbol changed or removed that was 
present in wheezy.

In the bugs alone we were at least 4 people who ran into the problem the 
other way around (updated cups but old libcups2), so it is likely that 
some people would have run into the problem if libcups2 in jessie will 
change or remove any of the internal symbols in the wheezy libcups2.

Assuming 1.5.3-4 in experimental doesn't remove or change any of the 
internal symbols in the wheezy libcups2, this was not an "actual bug" 
that could cause problems today. But it was a timebomb that could have 
become an actual bug people would run into at any time, even years after 
the release of wheezy.

> I have therefor uploaded 1.5.3-2.5, with the attached debdiff, implementing 
> the fix required by Adrian, to DELAYED/5 (to let the currently unblocked 
> 1.5.3-2.4 migrate to Wheezy). I don't plan to request an unblock for it.

Thanks a lot!

I'm therefore closing this tech-ctte bug.

> Cheers,
> OdyX



       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--- End Message ---

Reply to: