Bug#990128: libcurl4-gnutls-dev: Un-installable in multiarch environment: /usr/bin/curl-config differs

[Michael Schmeing]

Package: libcurl4-gnutls-dev
Version: 7.74.0-1.2
Severity: normal

When trying to install versions for different architectures of the package in a
multiarch environment, the installation fails for some combinations of
architectures, because /usr/bin/curl-config has differing contetns.

I have tested the architectures amd64, i386, arm64, armhf, and armel. Of these
architectures, only amd64 and i386 can be installed in parallel. In the others,
the curl-config script has one difference in line 174:

In the parameter "-ffile-prefix-map=/build/curl-mSxZiS/curl-7.74.0=.", the
portion "curl-mSxZiS" is different between architecture versions.

I have found the following variations:
x86_64, i386: curl-mSxZiS
arm64: curl-idFOZ7
armhf: curl-curl-cKdl1Z
armel: qDznpN

The string "curl-XXXXXX" seems to be a temporary filename, possibly created by
mktemp. Therefore, from my perspective, there appear two possible solutions:
1) Change the build process to use a fixed name rather than a generated one
2) Move curl-config to an architecture-independent package and make all
libcurl4-gnutls-dev packages depend on it.

NOTE:
I have not checked whether other libcurl4-???-dev packages (e.g.
libcurl4-openssl-dev) are affected as well. They may well be.




-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf, armel

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcurl4-gnutls-dev depends on:
ii libcurl3-gnutls 7.74.0-1.2

libcurl4-gnutls-dev recommends no packages.

Versions of packages libcurl4-gnutls-dev suggests:
pn libcurl4-doc <none>
ii libgnutls28-dev 3.7.1-5
ii libidn11-dev 1.33-3
ii libkrb5-dev 1.18.3-5
ii libldap2-dev 2.4.57+dfsg-3
ii librtmp-dev 2.4+20151223.gitfa8646d.1-2+b2
pn libssh2-1-dev <none>
ii pkg-config 0.29.2-1
ii zlib1g-dev 1:1.2.11.dfsg-2

[Helmut Grohne]

Control: tags -1 + patch

On Mon, Jun 21, 2021 at 02:45:52PM +0200, Michael Schmeing wrote:
> Version: 7.74.0-1.2

Yes, installation is broken in bullseye. This is bad and should be fixed
via a stable update.

> Severity: normal

I have to say that I concur with Adrian Bunk here. Unpack errors should
be serious.

> In the parameter "-ffile-prefix-map=/build/curl-mSxZiS/curl-7.74.0=.", the
> portion "curl-mSxZiS" is different between architecture versions.

It needs to be removed just like -fdebug-prefix-map=... is removed in
debian/rules. It's quite obvious after you see the diff actually.

> I have not checked whether other libcurl4-???-dev packages (e.g.
> libcurl4-openssl-dev) are affected as well. They may well be.

Yes, they are.

Any objections to NMUing this?

Helmut

[Michael Schmeing]

Hello,

a quite similar bug has been reintroduced in version 7.80.0-3 of
libcurl4-gnutls-dev:
The package is again unistallable in multiarch environments due to
differences in libcurl4-gnutls-dev. This time, it is the -L linker
options that contain the architecture triplet (e.g. amd64-linux-gnu, see
attached diff file).

Should this new difference in curl-config be handled by re-opening this
bug report or should I create a new one?

Best regards
Michael Schmeing

--
Michael Schmeing
Kahlhorststraße 36A
23562 Lübeck
E-Mail: mic...@michael-schmeing.de
Tel.: +49 451 30406604
Mobil: +49 176 22961510