[pkg-gnupg-maint] Bug#872806: libgpg-error0 packs runtime support files in shared library

[Sven Joachim]

Control: tags -1 + patch

Am 21.08.2017 um 14:53 schrieb Helmut Grohne:

> Package: libgpg-error0
> Version: 1.27-3
> Severity: serious
> Justification: policy 8.2
> User: helmutg at debian.org
> Usertags: rebootstrap
>
> libgpg-error0 packs runtime support files (i.e. .mo files) into the
> shared library package. It happens that these files are not versioned
> (e.g. libgpg-error.mo rather than libgpg-error0.mo). Doing so violates
> Debian policy section 8.2:
>
> |    If your package contains files whose names do not change with each change
> |    in the library shared object version, you must not put them in the shared
> |    library package. Otherwise, several versions of the shared library cannot
> |    be installed at the same time without filename clashes, making upgrades
> |    and transitions unnecessarily difficult.

There are a few other library package which include .mo files, but most
include the soname in their filename, so they don't have that problem.

> This happens to also break multiarch. Rebuilds of libgpg-error are not
> currently coinstallable with other instances from the archive:
>
> | Unpacking libgpg-error-dev:ppc64 (1.27-3) ...
> | dpkg: error processing archive /tmp/repo/pool/main/libg/libgpg-error/libgpg-error0_1.27-3_ppc64.deb (--unpack):
> |  trying to overwrite shared
> | '/usr/share/locale/cs/LC_MESSAGES/libgpg-error.mo', which is
> | different from other instances of package libgpg-error0:ppc64
> | Errors were encountered while processing:
> |  /tmp/repo/pool/main/libg/libgpg-error/libgpg-error0_1.27-3_ppc64.deb
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> | E: Failed to process build dependencies

This was apparently due to some changes in msgfmt's output format at the
time.  It does not seem to be a problem currently, but future changes in
msgfmt might bring it up again.

> I suggest moving them to an Arch:all package.

Attached is a patch which does that, introducing a libgpg-error-l10n
package with the translation files.  The exact Provides/Replaces
versions might have to be adjusted, and the exact relationship between
libgpg-error0 and libgpg-error-l10n is also debatable.  I have chosen an
unversioned Recommends, but others are also possible.  What would not
work is an exact "Depends: libgpg-error-l10n (= ${source:Version}),
since that breaks when libgpg-error1 comes along.

Cheers,
       Sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Move-the-translation-files-to-a-new-libgpg-error-l10.patch
Type: text/x-diff
Size: 2385 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20181012/1d6fef4b/attachment.patch>