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

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?

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

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

@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.

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

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

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 :/

@adamwill @cverna @fstephany I've made a new build that should fix it: https://src.fedoraproject.org/rpms/pkgconf/c/5dea89a881102185fe291a7a4902a10caa5b9a5e

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

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

@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...

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

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.

works

Works on the fedora container base image