libgpg-error symbol visibility

[Daniel Kahn Gillmor]

Hi Werner and other GnuPG folks--

I notice that libgpg-error 0.14 was released a few days ago --
thanks!

In addition to the addition of estream functionality, the biggest change
i see as a packager is the addition of symbol versioning visibility,
with a version node of GPG_ERROR_1.0.

IIUC, this actually moves all the pre-existing symbols from the "Base"
(implicit) version node to the new GPG_ERROR_1.0 version node, which
means that packages built against 0.14 but which only use pre-0.14
symbols will actually produce a (non-fatal) warning message when run
against a pre-0.14 version of libgpg-error.  For example:

0 dkg at alice:~$ echo test | gpg2 --encrypt -r $PGPID > tmp/test.pgp
gpg2: /lib/x86_64-linux-gnu/libgpg-error.so.0: no version information available (required by gpg2)
0 dkg at alice:~$ 

I don't know enough about symbol versioning to know if there's a way to
produce a smoother upgrade path.  I've tried a couple different
approaches, but none of them worked so i have no patch to propose.

I'm trying to prepare this version for upload to Debian before we freeze
(soon!), and i want to make sure that we're doing the right thing with
it.  At the moment, i'm looking for alternatives to the default option:

 A) ship 0.14 as-is, with all symbols bound to the new GPG_ERROR_1.0
    version node, and accept that this will force an unnecessarily
    strong versioned dependency for packages built against the new
    package but only using pre-existing symbols.

Is there a way that we can avoid this tighter versioned dependency and
still avoid the warning messages shown above, or should we just accept
the tight dependency and move forward?

The tight versioned dependency will make backporting packages that
depend on libgpg-error slightly more painful, but it's probably not a
terrible thing.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20140911/73b3317f/attachment.sig>