libgpg-error symbol visibility

[Andreas Metzler]

In gmane.comp.encryption.gpg.devel Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
[...]
> 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?

Hello,

I think that is the correct thing to do, and it should not bother
us at Debian a lot. 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.)

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

Afaiui this will not not complicate backporting either. Backports of
libgpg-error using packages will be built against the native (older)
libgpg-error version. That is unless they require features from the
newer libgpg-error. Then somebody will need to provide a backport
of that package first and the backport will be built against it and
wil depend on it.

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'