Description of problem: The annobin package has no versioned gcc dependency to enforce build->runtime compatibility restriction (annobin only works with the gcc it was built with). It looks like the spec has this stuff, but it was put in the wrong place, so it has no effect at all. Please move it above the %description section for the main package so that it actually takes effect. Version-Release number of selected component (if applicable): 8.16-1.fc29 [Rawhide/F29] 5.7-2.fc28 [F28] 2.0-3.fc27 [F27] How reproducible: Always
Hi Neal, Moving the requirement as you describes causes the build to fail with this error: sh: gcc: command not found gawk: cmd. line:1: warning: escape sequence `\)' treated as plain `)' error: line 87: Version required: Requires: gcc == As can be seen here, whilst the scratch build lasts:https://koji.fedoraproject.org/koji/taskinfo?taskID=28545292 It seems like a bit of a chicken and egg situation. The spec file needs gcc in order to be able to compute the version of gcc that it needs. :-) Any suggestions ? Cheers Nick
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This just bit me when I did "dnf update --exclude=gcc" on rawhide and annobin got updated to the gcc 9 version, breaking the compiler...
(In reply to Nick Clifton from comment #1) > > Moving the requirement as you describes causes the build to fail with this > error: > > sh: gcc: command not found > gawk: cmd. line:1: warning: escape sequence `\)' treated as plain `)' > error: line 87: Version required: Requires: gcc == > > As can be seen here, whilst the scratch build > lasts:https://koji.fedoraproject.org/koji/taskinfo?taskID=28545292 > > It seems like a bit of a chicken and egg situation. The spec file needs > gcc in order to be able to compute the version of gcc that it needs. :-) > > Any suggestions ? > You can BR gcc, and then use rpm in the spec to identify the version-release of gcc installed, and set that as the _exact_ requirement. %define gcc_runtime_req_version %(rpm -q --qf '%{version}-%{release}' gcc) BuildRequires: gcc Requires: gcc = %{gcc_runtime_req_version} Note that the usage of %define is intentional, as it means it's evaluated when it is used, not when the spec is initially parsed.
(In reply to Neal Gompa from comment #4) Hi Neal, > %define gcc_runtime_req_version %(rpm -q --qf '%{version}-%{release}' gcc) > > BuildRequires: gcc > Requires: gcc = %{gcc_runtime_req_version} > > Note that the usage of %define is intentional, as it means it's evaluated > when it is used, not when the spec is initially parsed. Annobin only requires compatibility with gcc's major version number, not its minor version. So could I just use: %define gcc_runtime_req_version %(rpm -q --qf '%{version}' gcc) Or will this not work as a requirement ? Cheers Nick
(In reply to Nick Clifton from comment #5) > (In reply to Neal Gompa from comment #4) > > Hi Neal, > > > %define gcc_runtime_req_version %(rpm -q --qf '%{version}-%{release}' gcc) > > > > BuildRequires: gcc > > Requires: gcc = %{gcc_runtime_req_version} > > > > Note that the usage of %define is intentional, as it means it's evaluated > > when it is used, not when the spec is initially parsed. > > Annobin only requires compatibility with gcc's major version number, not its > minor version. So could I just use: > > %define gcc_runtime_req_version %(rpm -q --qf '%{version}' gcc) > > Or will this not work as a requirement ? > > Cheers > Nick As long as you're confident it won't break, that's fine.
OK then. Fixed in annobin-8.69-2.fc30.
(In reply to Nick Clifton from comment #7) > OK then. Fixed in annobin-8.69-2.fc30. That version had 'Requires: gcc = 8.69'. Fully wrong and broke rawhide. I've fixed that in annobin-8.69-4.fc30, which now has 'Requires: gcc = 9.0.1'. But even that is wrong… Let me see if I can fix the requirement to 'Requires: (gcc >= 9 AND gcc < 10)', which would be the actually correct requirement.
Fixed in annobin-8.69-5.fc30. annobin-8.69-5.fc30: Requires: (gcc >= 9 AND gcc < 10).
Strictly I think you want (gcc >= 9 with gcc < 10) so that both requirements are satisfied by the same package although that's only really an issue if it's possible to have multiple packages installed providing different versions of "gcc".
(In reply to Tom Hughes from comment #10) > Strictly I think you want (gcc >= 9 with gcc < 10) so that both requirements > are satisfied by the same package although that's only really an issue if > it's possible to have multiple packages installed providing different > versions of "gcc". It is possible for that, so yes, you'd want `with`, not `and`. Think about the modularity madness.
Well modularity, as they keep telling us, only permits parallel availability, not parallel installability ;-)
I've change the rich dependency to Requires: (gcc >= %{gcc_major} with gcc < %{gcc_next}) in annobin-8.69-6.f30, just for safety.
(In reply to Tom Hughes from comment #12) > Well modularity, as they keep telling us, only permits parallel > availability, not parallel installability ;-) If there are no filesystem conflicts, it's actually possible to do parallel installable ones too. The Python modules work that way in RHEL 8.
(In reply to Björn 'besser82' Esser from comment #13) > I've change the rich dependency to Requires: (gcc >= %{gcc_major} with gcc < > %{gcc_next}) in annobin-8.69-6.f30, just for safety. Thanks for fixing this. I really am a noob when it comes to spec file syntax. Cheers Nick
You're welcome! =) Another note on this: Since `redhat-rpm-config` requires `annobin if gcc`, there must be a build of annobin without strict version requirement present in the Rawhide buildroots *before* a new major version of gcc lands. Otherwise the buildroot will be broken and needs bootstrapping with touching several pacakges.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.