FEDORA-2020-1553536645 created by ngompa a week ago for Fedora 33
stable

Eliminate multilib conflict on /usr/bin/pkg-config

How to install

sudo dnf upgrade --advisory=FEDORA-2020-1553536645

This update has been submitted for testing by ngompa.

a week ago

This update's test gating status has been changed to 'ignored'.

a week ago

This update's test gating status has been changed to 'waiting'.

a week ago

This update's test gating status has been changed to 'ignored'.

a week ago

ngompa edited this update.

New build(s):

  • pkgconf-1.7.3-4.fc33

Removed build(s):

  • pkgconf-1.7.3-3.fc33

Karma has been reset.

a week ago

This update has been pushed to testing.

a week ago
User Icon geraldosimiao commented & provided feedback a week ago
karma

I managed to install both on my F33kde. Working fine.

Only this side effect: it downgrade this packages: cpp x86_64 10.2.1-3.fc33 fedora 9.3 M gcc x86_64 10.2.1-3.fc33 fedora 30 M gcc-gdb-plugin x86_64 10.2.1-3.fc33 fedora 133 k libgcc x86_64 10.2.1-3.fc33 fedora 97 k libgomp x86_64 10.2.1-3.fc33 fedora 258 k

BZ#1878909 pkgconf-pkg-config generates file conflict between i686 & x86_64 packages

This update has been submitted for stable by bodhi.

a week ago
User Icon atim provided feedback 6 days ago
karma
User Icon frantisekz provided feedback 5 days ago
karma
User Icon fstephany commented & provided feedback 5 days ago

This change seems to break my F33 beta installation.

$ cat /usr/bin/pkg-config
#!/usr/bin/sh

# Multilib safe wrapper for pkg-config to call correct platform-specific version of pkg-config

TARGET_PLATFORM=$(rpm --eval '%{_target_platform}')

exec "/usr/bin/${TARGET_PLATFORM}-pkg-config" "$@"

$ rpm --eval "%{_host}"
x86_64-redhat-linux-gnu
$ rpm --eval '%{_target_platform}'
x86_64-redhat-linux
$ ls /usr/bin/*-pkg-config
/usr/bin/x86_64-redhat-linux-gnu-pkg-config

The missing gnu part result in the following error:

~~~ $ pkg-config --cflags --libs openssl /usr/bin/pkg-config: line 7: /usr/bin/x86_64-redhat-linux-pkg-config: No such file or directory ~~

From what I could gather, this commit seems to be the source of the change.

I'm pretty new to Fedora and reporting bugs to a distro. Is here the right place to report? Have I missed something?

User Icon ngompa commented & provided feedback 5 days ago

@fstephany How is that happening? %_target_platform should be defined correctly: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/macros#_8

User Icon cverna commented & provided feedback 4 days ago

It seems that this is also breaking the container images see https://github.com/fedora-cloud/docker-brew-fedora/issues/81

User Icon fstephany commented & provided feedback 4 days ago

@ngompa indeed, this is weird, it looks like the -gnu suffix is added with the macro expansion.

I have no idea where to look and I know next to nothing to RPM packaging :/ Just in case here's the rpm version that is currently installed (clean F33 beta install, with frequent dnf update)

$ rpm -qf `which rpm`
rpm-4.16.0-1.fc33.x86_64

Let me know if I can provide more input.

User Icon ngompa commented & provided feedback 4 days ago

@fstephany This is starting to sound like a bug in RPM. :(

User Icon adamwill commented & provided feedback 4 days ago

OK, while there are issues with this I'm not gonna include it in any stable push requests.

User Icon adamwill commented & provided feedback 4 days ago
karma

I see the problem here.

In the rpm package itself, %_target_platform is defined for each platform in a file under /usr/lib/rpm/platform/, always the same:

[adamw@adam nightlies]$ rpm -ql rpm | grep -v rpmdb.sqlite | xargs strings -f 2>/dev/null | grep -s target_platform
/usr/lib/rpm/platform/aarch64-linux/macros: %_target_platform   %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alpha-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev5-linux/macros: %_target_platform  %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev56-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev6-linux/macros: %_target_platform  %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev67-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}

etc. etc. etc. But there is another definition that overrides that one, which may or may not be present on any given system. It's in /usr/lib/rpm/redhat/macros, which is part of the redhat-rpm-config package:

[adamw@adam nightlies]$ grep target_platform /usr/lib/rpm/redhat/macros 
%_target_platform   %{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu}
[adamw@adam nightlies]$ rpm -qf /usr/lib/rpm/redhat/macros
redhat-rpm-config-172-1.fc33.noarch

That's where the -gnu on the end comes from. If you have redhat-rpm-config package installed, %_target_platform will evaluate to something like x86_64-redhat-linux-gnu. If you don't have it installed, %_target_platform will evaluate to something like x86_64-redhat-linux.

I'm pretty sure that package is always installed during package builds, hence during the build of the package we get the -gnu form and the binaries get installed using that form, as /usr/bin/x86_64-redhat-linux-gnu-pkg-config etc. But the wrapper script is running on the local system, and we can't be sure that the redhat-rpm-config package is installed there; it's not a dependency of anything very critical. In general packagers will have it installed, but otherwise it may very well not be installed.

So the wrapper script cannot really be reliable as written. An ugly hack would be to add the -gnu to the end of the string if it's not there already :/

ngompa edited this update.

New build(s):

  • pkgconf-1.7.3-5.fc33

Removed build(s):

  • pkgconf-1.7.3-4.fc33

Karma has been reset.

4 days ago

This update has been submitted for testing by ngompa.

4 days ago
User Icon adamwill commented & provided feedback 4 days ago

so that'll work just so long as we don't have any lurking packages anywhere that redefine any of those things...:)

ngompa edited this update.

3 days ago
User Icon fstephany commented & provided feedback 3 days ago

Thanks for the digging @adamwill. Hopefully there aren't any other package that redefines those macros.

In the meantime, shouldn't this issue be raised to the maintainers of redhat-rpm-config? Overriding existing macros sounds dangerous from an outsider perspective :p

This update has been pushed to testing.

3 days ago
User Icon ngompa commented & provided feedback 3 days ago

@fstephany That's actually what redhat-rpm-config is supposed to do. It's a set of vendor overrides. However, in this case, I'm not sure why that definition isn't present in RPM itself...

User Icon adamwill commented & provided feedback 3 days ago

I vaguely remember the whole -gnu thing being some kind of hot debate years ago, but I don't recall the details at all :/

User Icon fstephany commented & provided feedback 2 days ago

Oh got it.

From the package description (Macros and scripts for building kernel module packages) I thought it was only useful for people building kernel modules.

User Icon scorreia provided feedback 2 days ago
karma
BZ#1889192 pkgconf-pkg-config points to non-exising file

This update has been submitted for stable by bodhi.

2 days ago
User Icon geraldosimiao commented & provided feedback 2 days ago
karma

works

BZ#1878909 pkgconf-pkg-config generates file conflict between i686 & x86_64 packages
User Icon cverna commented & provided feedback 2 days ago
karma

Works on the fedora container base image

ngompa edited this update.

20 hours ago

This update has been pushed to stable.

3 hours ago

Please login to add feedback.

Metadata
Type
bugfix
Karma
3
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
1
Stable by Time
14 days
Dates
submitted
a week ago
in testing
3 days ago
in stable
3 hours ago
modified
20 hours ago
BZ#1878909 pkgconf-pkg-config generates file conflict between i686 & x86_64 packages
0
1
BZ#1889192 pkgconf-pkg-config points to non-exising file
0
1
BZ#1890248 checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... /usr/bin/pkg-config: line 7: /usr/bin/x86_64-redhat-linux-pkg-config: No such file or directory
0
0

Automated Test Results