[Pkg-gnupg-maint] libgpg-error symbol visibility

[Daniel Kahn Gillmor]

[dropping gnupg-devel, limiting to pkg-gnupg-maint since this is now
debian-specific discussion]

On 09/11/2014 01:01 PM, Werner Koch wrote:
> On Thu, 11 Sep 2014 18:19, dkg at fifthhorseman.net said:
> 
>> I notice that libgpg-error 0.14 was released a few days ago --
> 
> Well, I released 1.15 today and removed 1.14 from the ftp server:
> 
>  * This releases fixes problems with the use of off_t and ssize_t by
>    the estream functions introduced with 1.14.  Although this is
>    technically an ABI break on some platforms, we take this as a
>    simple bug fix for 1.14.  The new functions are very unlikely in
>    use by any code and thus no breakage should happen.  The 1.14
>    tarball will be removed from the archive.
> 
>  * Add type gpgrt_off_t which is guaranteed to be 64 bit.
> 
>  * Add type gpgrt_ssize_t to make use on Windows easier.  On Unix
>    platforms this is an alias for ssize_t.


I've just pushed 1.15 into our git repos, along with packaging that
works with it for me.

>> 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.
> 
> This should have been done much earlier.  I must have missed that in the
> past.
> 
>> 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
> 
> Interesting but I see that this can be a useful warning.
> 
>> produce a smoother upgrade path.  I've tried a couple different
>> approaches, but none of them worked so i have no patch to propose.
> 
> The whole purpose of the arning is to tell about possible problems. I do
> not think that there will be any problems, though.  Unfortunatley
> libgpg-error is used used by Libgcrypt and thus a lot of software will
> be bugged by this warning.
> 
>>  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.
> 
> After all it is only a warning which will should go away after all
> packages have been rebuild.
> 
>> 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 do not think that this is really a dependency.

So i'm wondering if other folks in pkg-gnupg have an opinion on this.

In practice, because of our shlibdeps symbol tracking, debian will treat
these newly-versioned symbols as a hard dependency.  This avoids users
ever seeing the kind of warning mentioned above.

The added pain of backporting libgpg-error when backporting its reverse
deps doesn't seem too bad for me.

So i'm inclined to go forward with the upload even though it'll cause
tighter dependencies.   I don't think it will be too disruptive, and it
sounds like upstream isn't interested in trying to split out the symbol
versioning to distinguish pre-version-node symbols from the new
versioned symbols.

But if anyone from pkg-gnupg thinks this will be a problem, please speak
up.  I'd be interested in hearing any alternate suggestions.

> I would fear more the new constructor which adds an atexit callback and
> uses a lock in the callback

This part makes me nervous but i confess i don't see how it would be
likely to cause problems.

We probably want to make a decision soon, so that if there are any
problems that come from the change we can fix them before the freeze.

Any thoughts?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20140912/b830e634/attachment.sig>