libgpg-error symbol visibility
ametzler at bebt.de
Fri Sep 12 18:50:11 CEST 2014
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?
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
> 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.
`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 Gnupg-devel