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.
@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)
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:
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 :/
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...
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
This update has been submitted for testing by ngompa.
This update's test gating status has been changed to 'ignored'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'ignored'.
ngompa edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been pushed to testing.
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 update has been submitted for stable by bodhi.
This change seems to break my F33 beta installation.
The missing
gnupart 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_platformshould be defined correctly: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/macros#_8It 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
-gnusuffix 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)
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_platformis defined for each platform in a file under/usr/lib/rpm/platform/, always the same: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 theredhat-rpm-configpackage:That's where the
-gnuon the end comes from. If you haveredhat-rpm-configpackage installed,%_target_platformwill evaluate to something likex86_64-redhat-linux-gnu. If you don't have it installed,%_target_platformwill evaluate to something likex86_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
-gnuform and the binaries get installed using that form, as/usr/bin/x86_64-redhat-linux-gnu-pkg-configetc. But the wrapper script is running on the local system, and we can't be sure that theredhat-rpm-configpackage 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
-gnuto the end of the string if it's not there already :/ngompa edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by ngompa.
@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...:)
ngompa edited this update.
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.
@fstephany That's actually what
redhat-rpm-configis 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
-gnuthing 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.
This update has been submitted for stable by bodhi.
works
Works on the fedora container base image
ngompa edited this update.
This update has been pushed to stable.