Bug#765430: ldd: no version information available (required by /lib/x86_64-linux-gnu/libgcrypt.so.20)

Andreas Metzler ametzler at bebt.de
Thu Oct 16 17:36:58 UTC 2014


Control: reassign -1 libgpg-error0 1.15-1

On 2014-10-15 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> On 10/15/2014 05:03 PM, Tim Connors wrote:
> > Note that in that thread, "Our users will never see the warning message
> > since packages built against the newer gpg-error will depend on it and
> > packages built against the old one will not show the warning either. (I
> > have not actually run any tests to verify this, but I guess you did.)"

> > We do see the warning message, because the likes of a later version of
> > libgcrypt doesn't appear to depend on the required version of
> > libgpg-error (it depends on >= 1.10, whereas it appears from that
> > discussion to have been built against >=1.15).

Hello,
Well, what actually happened was:
  f0f0d949734e4841070bab1971700df1463c3b24
  Pre-existing symbols (those that used to be marked @Base) have been
  brought into the GPG_ERROR_1.0 version node, but i've marked them as
  present in earlier versions of the package -- tools compiled against
  newer versions, but which just use these older symbols should be
  installable with older versions of libgpg-error.

i.e. at the time of the respective libgpg-error upload, Daniel thought
it was better to not have have a stricter dependency which only
avoided a warning message.

> hm, i suppose this means that we might want to bump the .symbols file in
> libgpg-error0 to refer to 1.15 for all symbols since the version node
> was introduced there?

> that seems like it would be similar to a library transition, though, and
> i know that the release team is frowning on that at this late date, and
> it would be entirely for the purpose of avoiding a warning (not an error).

> I'm not sure this would be worth the tradeoff, but i'm willing to
> consider it if people feel strongly about it.

I think it would be a good idea and do not think this is like a
library transition at all. libgpg-error is up to date in testing
(1.16). - Bumping the version-dependency of the affected symbols to
1.15 in the symbol file will not hurt or delay testing propagation of
reverse dependencies.

This more like uploading a new upstream versions of shared
library (without symbol file) bumping the shlibs. (Which ist still
allowed.) Just without the possibly negative effect of delaying other
packages.

What would make it a little bit like a library transition is if you
later asked -release to binnmu all libgpg-error reverse dependencies
to make sure they got a strict dependency. I guess they would do it if
they had buildd time to spare. But this is a optional second step. If
-release does not want to, nothing is lost.

Anyway. Daniel, I am reassigning to libgpg-error0, since that is where
the fix will need to happen. Please simply send it back if you
disagree.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



More information about the Pkg-gnutls-maint mailing list