Bug#692155: Please

[Jonathan Nieder]

Russ Allbery wrote:

> Actually, it could ship in the regular shared library path.  It would just
> change its SONAME a lot, which would be fine, since no other applications
> would link against it and therefore no one would really care.  And indeed
> it would probably have to be in the public search path because libcups
> itself would doubtless need to depend on it.

Would setting DT_RUNPATH on libcups work to avoid that?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#692155: Please

[Adrian Bunk]

On Fri, Nov 02, 2012 at 04:41:19PM -0700, Russ Allbery wrote:
> "Didier 'OdyX' Raboud"  writes:
>...
> > Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit :
> >> In practice, divergence from the upstream SONAME practice is probably a
> >> bad idea.  This business of having an exposed private API is dangerous and
> >> constitutes bad API design on upstream's part, but that's not something
> >> that we can easily fix in Debian, and diverging too far from upstream is
> >> probably counter-productive.
> 
> > That's the crux of the problem indeed. The "good way" would be to have a
> > libcupsprivate, shipping its objects outside of standard library paths,
> > right?  Sounds like an invasive bug, not sure that it would be worth the
> > work.
> 
> Actually, it could ship in the regular shared library path.  It would just
> change its SONAME a lot, which would be fine, since no other applications
> would link against it and therefore no one would really care.
>...

Having a SONAME for such a library would cause other problems, e.g. the 
changes cherry-picked into 1.5.2-8 (that caused #668662) could result in 
a private library whose ABI would not match any upstream SONAME.

Not an unsolvable problem (one could even automatically encode version 
and Debian revision into the SONAME), but also not much nicer than the
status quo.

> The solution that I use is to just refuse to let myself use the concept of
> a private API and make all of the things used internally by my software
> public APIs as well, absorbing the maintenance costs that entails.  But I
> understand why people don't do that.  :/
>...

Sharing code between different components (that are in different Debian 
packages) in a software with much development going on without having to 
continue to provide and maintain any such shared code for 10-20 years is 
the problem CUPS is trying to solve that way.

Creating a libcupsprivate that is a static library (which also has
it's drawbacks) might be another approach for an upstream to solve
this problem.

cu
Adrian

-- 

   "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


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#692155: Please

[Russ Allbery]

"Didier 'OdyX' Raboud"  writes:

> Thanks for your detailed summary, it's very helpful.

Glad!

> Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit :
>> In practice, divergence from the upstream SONAME practice is probably a
>> bad idea.  This business of having an exposed private API is dangerous and
>> constitutes bad API design on upstream's part, but that's not something
>> that we can easily fix in Debian, and diverging too far from upstream is
>> probably counter-productive.

> That's the crux of the problem indeed. The "good way" would be to have a
> libcupsprivate, shipping its objects outside of standard library paths,
> right?  Sounds like an invasive bug, not sure that it would be worth the
> work.

Actually, it could ship in the regular shared library path.  It would just
change its SONAME a lot, which would be fine, since no other applications
would link against it and therefore no one would really care.  And indeed
it would probably have to be in the public search path because libcups
itself would doubtless need to depend on it.  (And it would probably have
to expose even more symbols than it currently does to provide the API that
libcups would need.)

The solution that I use is to just refuse to let myself use the concept of
a private API and make all of the things used internally by my software
public APIs as well, absorbing the maintenance costs that entails.  But I
understand why people don't do that.  :/

In any event, this is not the sort of thing that Debian should do
independent of upstream.  It's way, way too invasive.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#692155: Please

[Didier 'OdyX' Raboud]

Hi Russ,

Thanks for your detailed summary, it's very helpful.

Le vendredi, 2 novembre 2012 23.47:11, Russ Allbery a écrit :
> In practice, divergence from the upstream SONAME practice is probably a
> bad idea.  This business of having an exposed private API is dangerous and
> constitutes bad API design on upstream's part, but that's not something
> that we can easily fix in Debian, and diverging too far from upstream is
> probably counter-productive.

That's the crux of the problem indeed. The "good way" would be to have a 
libcupsprivate, shipping its objects outside of standard library paths, right? 
Sounds like an invasive bug, not sure that it would be worth the work.

Cheers,

OdyX


signature.asc
Description: This is a digitally signed message part.

Bug#692155: Please

[Russ Allbery]

"Didier 'OdyX' Raboud"  writes:

> f) that the vast majority of library depencies are handled with ">="
>dependencies despite no technical guarantees of ABI stability (besides
>Debian-specific symbol tracking);

While there are no *technical* guarantees, there is the expectation that
anyone maintaining a shared library will increase the SONAME when there is
any non-backward-compatible change to a public symbol.  Not doing this is
a Policy violation, and is usually release-critical (although this can
depend on the situation).

Unsupported internal APIs are one of the possible exceptions.  We just
rewrote this section in the most recent Policy update to try to make it
clearer.

8.1:

Every time the shared library ABI changes in a way that may break
binaries linked against older versions of the shared library, the
SONAME of the library and the corresponding name for the binary
package containing the runtime shared library should change.
Normally, this means the SONAME should change any time an interface is
removed from the shared library or the signature of an interface (the
number of parameters or the types of parameters that it takes, for
example) is changed.  This practice is vital to allowing clean
upgrades from older versions of the package and clean transitions
between the old ABI and new ABI without having to upgrade every
affected package simultaneously.

8.6.2:

There are two types of ABI changes: ones that are backward-compatible
and ones that are not.  An ABI change is backward-compatible if any
reasonable program or library that was linked with the previous
version of the shared library will still work correctly with the new
version of the shared library.[71]  Adding new symbols to the shared
library is a backward-compatible change.  Removing symbols from the
shared library is not.  Changing the behavior of a symbol may or may
not be backward-compatible depending on the change; for example,
changing a function to accept a new enum constant not previously used
by the library is generally backward-compatible, but changing the
members of a struct that is passed into library functions is generally
not unless the library takes special precautions to accept old
versions of the data structure.

[71] An example of an "unreasonable" program is one that uses library
  interfaces that are documented as internal and unsupported.  If the
  only programs or libraries affected by a change are "unreasonable"
  ones, other techniques, such as declaring Breaks relationships with
  affected packages or treating their usage of the library as bugs in
  those packages, may be appropriate instead of changing the SONAME.
  However, the default approach is to change the SONAME for any change
  to the ABI that could break a program.

In practice, divergence from the upstream SONAME practice is probably a
bad idea.  This business of having an exposed private API is dangerous and
constitutes bad API design on upstream's part, but that's not something
that we can easily fix in Debian, and diverging too far from upstream is
probably counter-productive.  Therefore, I think using a tight (=)
dependency for consumers of the private API is a reasonable compromise
given the situation as I understand it.

I do recommend doing something that will happen automatically without the
packager having to think about it if this is a common occurance (not, for
example, a one-time change to the private interface that only happens
every five years or so), such as a hardcoded = dependency in
debian/control.

> g) that, to my knowledge, too-tight dependencies hurt upgrade paths;

Insufficiently tight dependencies to guarantee that software continues to
work properly hurts upgrade paths even more.  :)  We should not be
reluctant to use our dependency system accurately and expect the
dependency resolvers to work properly.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#692155: Please

[Don Armstrong]

On Fri, 02 Nov 2012, Didier 'OdyX' Raboud wrote:
> Now, as I already wrote, "I will be happy to have my judgment
> challenged." That's still true, so I'll let the either the tech-ctte
> or the bugreporter further handle this bug if considered necessary:
> I don't feel like closing it myself.

Thanks to you both for working to resolve this issue.

Adrian: does this resolve the problem? If so, please close the bug.
[It can always be reopened again if there is some future
disagreement.]



Don Armstrong

-- 
I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
 -- Patrick McGoohan as Number 6 in "The Prisoner"

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#692155: Please

[Didier 'OdyX' Raboud]

Hi dear CTTE members, hi Adrian,

Considering:
a) that I have (possibly wrongly) interpreted Adrian's #668662#105 [0] as
   offensive (and therefor took it too personally);
b) that I have therefor over-reacted in #668662#118 [1], including a call to
   appeal to the tech-ctte, probably unneeded;
c) that I have intially fixed #668662 by cherry-picking the fix released in
   experimental (so that the claimed mis-fix is arguably a genuine overlook);
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);
f) that the vast majority of library depencies are handled with ">="
   dependencies despite no technical guarantees of ABI stability (besides
   Debian-specific symbol tracking);
g) that, to my knowledge, too-tight dependencies hurt upgrade paths;
h) … but that, arguably, the handling of private symbols in cups as shipped in
   1.5.3-2.4 is weak;
h) that there are more important things in Debian to work on these days (like
   releasing Wheezy for example);

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.

Now, as I already wrote, "I will be happy to have my judgment challenged." 
That's still true, so I'll let the either the tech-ctte or the bugreporter 
further handle this bug if considered necessary: I don't feel like closing it 
myself.

Cheers,

OdyX

--
[0] http://bugs.debian.org/668662#105
[1] http://bugs.debian.org/668662#118
diff -Nru cups-1.5.3/debian/changelog cups-1.5.3/debian/changelog
--- cups-1.5.3/debian/changelog	2012-10-25 08:56:38.0 +0200
+++ cups-1.5.3/debian/changelog	2012-11-02 22:31:02.0 +0100
@@ -1,3 +1,9 @@
+cups (1.5.3-2.5) unstable; urgency=low
+
+  * Furhter tighten cups dependency on libcups2. (Closes: #668662)
+
+ -- Didier Raboud   Fri, 02 Nov 2012 22:30:39 +0100
+
 cups (1.5.3-2.4) unstable; urgency=low
 
   * Non-maintainer upload on behalf of the Printing Team.
diff -Nru cups-1.5.3/debian/control cups-1.5.3/debian/control
--- cups-1.5.3/debian/control	2012-10-24 11:13:41.0 +0200
+++ cups-1.5.3/debian/control	2012-11-02 22:25:35.0 +0100
@@ -162,7 +162,7 @@
  lsb-base (>= 3),
  cups-common (>= ${source:Upstream-Version}), 
  cups-client (>= ${binary:Version}),
- libcups2 (>= ${binary:Version}),
+ libcups2 (= ${binary:Version}),
  ssl-cert (>= 1.0.11),
  adduser,
  bc,


signature.asc
Description: This is a digitally signed message part.

Bug#692155: Please

[Adrian Bunk]

Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
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})".


Explanation:

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
stability.

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
library.

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



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlCUFhIACgkQmfzqmE8StADzPwCgm/83XHgvj5ThxIqa3SFc0d2R
srQAni0JUAbFFhJFffYrlpGxwrZrS9jO
=lG5J
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org