* Emilio Pozuelo Monfort: > > I assume at this point that means bumping the shlibs to get proper > dependencies.
That was my initial idea, too, but I have given additional thought to this and I think that this is not the right thing to do. Just to make sure we are all discussing the same thing, this is what updating the shlibs would look like: --- a/debian/libcdio19t64.symbols +++ b/debian/libcdio19t64.symbols @@ -1,3 +1,3 @@ libcdio.so.19 libcdio19t64 #MINVER# * Build-Depends-Package: libcdio-dev - (symver)CDIO_19 2.1.0 + (symver)CDIO_19 2.2.0 The collateral effect of this change is that any package that depends on libcdio(-dev) and that gets rebuilt in the future, will start to require libcdio version 2.2.0, when they should be able to work with the older 2.1.0, because libcdio did not break its ABI. As such, I think that updating the .symbols file is abusing the symbols/shlibs system and "unnecessarily restrict use of the package on systems with older versions of the shared libraries"[1]. [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html Alternatively, we could make libiso9660 (and libiso9660++) explicitly depend on the newer version of libcdio. What I mean by this is more clearly described by the following diff: --- a/debian/control +++ b/debian/control @@ -115 +115 @@ Pre-Depends: ${misc:Pre-Depends} -Depends: ${shlibs:Depends}, ${misc:Depends} +Depends: ${shlibs:Depends}, ${misc:Depends}, libcdio19t64 (>= 2.2.0) @@ -124 +124 @@ Pre-Depends: ${misc:Pre-Depends} -Depends: ${shlibs:Depends}, ${misc:Depends} +Depends: ${shlibs:Depends}, ${misc:Depends}, libcdio19t64 (>= 2.2.0) This restricts the effect of the fix only to libiso9660 (and libiso9660++). This makes more sense to me, since it was only these libraries that had an ABI break. Does anybody has any thoughts about this?
