#27 Switch to using the dist_ macros for distribution-specific configuration
Opened 5 months ago by amitshah. Modified 2 months ago
rpms/ amitshah/gcc dist-macros  into  rawhide

file modified
+6 -3
@@ -125,7 +125,7 @@ 

  Summary: Various compilers (C, C++, Objective-C, ...)

  Name: gcc

  Version: %{gcc_version}

- Release: %{gcc_release}%{?dist}

+ Release: %{gcc_release}%{?dist}.1

  # libgcc, libgfortran, libgomp, libstdc++ and crtstuff have

  # GCC Runtime Exception.

  License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and LGPLv2+ and BSD
@@ -905,7 +905,7 @@ 

  	--target nvptx-none --enable-as-accelerator-for=%{gcc_target_platform} \

  	--enable-languages=c,c++,fortran,lto \

  	--prefix=%{_prefix} --mandir=%{_mandir} --infodir=%{_infodir} \

- 	--with-bugurl=http://bugzilla.redhat.com/bugzilla \

+ 	--with-bugurl=%{?dist_bug_report_url} \

  	--enable-checking=release --with-system-zlib \

  	--with-gcc-major-version-only --without-isl

  make %{?_smp_mflags}
@@ -957,7 +957,7 @@ 

  %endif

  CONFIGURE_OPTS="\

  	--prefix=%{_prefix} --mandir=%{_mandir} --infodir=%{_infodir} \

- 	--with-bugurl=http://bugzilla.redhat.com/bugzilla \

+ 	--with-bugurl=%{?dist_bug_report_url} \

  	--enable-shared --enable-threads=posix --enable-checking=release \

  %ifarch ppc64le

  	--enable-targets=powerpcle-linux \
@@ -3217,6 +3217,9 @@ 

  %endif

  

  %changelog

+ * Wed Oct 5 2022 Amit Shah <amitshah@fedoraproject.org> - 12.2.1-2.1

+ - Use the dist_bug_report_url macro, fixes bugzilla URL

+ 

  * Wed Sep 07 2022 Kalev Lember <klember@redhat.com> 12.2.1-2

  - enable GDC on aarch64

  

The new dist_vendor and dist_bug_report_url macros[1] in fedora-release
help simplify spec files by removing the conditionals for populating the
distro.

For Fedora, this means that the gcc version will now be advertised as
'Fedora 12.1.1-3' instead of 'Red Hat 12.1.1-3'.

It also changes the bugzilla URL to drop the trailing '/bugzilla' in the
link -- which is a positive change. The old URL did not resolve to
a working web page.

[1] https://src.fedoraproject.org/rpms/fedora-release/pull-request/223

Note: if it's not desirable to replace the vendor to Fedora from Red Hat, I can add a conditional to switch it back on Fedora. However, clang, gdb, etc., all use Fedora as the vendor, and gcc is the only outlier (as far as I've seen so far), so perhaps this is fine?

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci

I think I'm fine with this change. Do the dist_vendor and dist_bug_report_url macros work on RHEL as well?

@mpolacek The RHEL bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=2112392

This wasn't filed through proper channels (partner management or customer support), so it's unclear if it's going to make it.

Thanks Florian. I hadn't seen that one (it's not filed against gcc).

At least the DEV-PHASE change looks wrong, it identifies the Red Hat gcc branch, not whomever packaged the compiler from it.
And, I don't see those macros in my f36 and the same spec file is used for f36..f38.

I'll backport the macros to F35 and F36 as well.

I don't get the comment about the RH gcc branches and how that changes things.

The centos change in https://gitlab.com/redhat/centos-stream/rpms/centos-release/-/merge_requests/33 is merged now. The RHEL bug I filed was acc to the centos guidelines; not sure if that needs to change in some way. Thanks Florian for getting attention on the bug.

I'm also testing a fallback for the cases where the dist_ macros aren't defined (eg in RHEL).

@amitshah No worries, I think I got the RHEL bug unstuck. It was easier than expected, sorry for the false alarm.

I think Jakub suggests to keep using the Red Hat vendor string as long as the sources are taken from one of the the /redhat/ upstream branch, for example this one: https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/vendors/redhat/heads/gcc-12-branch (This uses a bit of an obscure Git feature.)

Note, it isn't just estitical thing, but the compiler actually behaves differently depending on the exact vendor read from DEV-PHASE.

Hm; is the vendor/DEV-PHASE bit overloaded, then?

For example, with a change like this:

-echo 'Red Hat %{version}-%{gcc_release}' > gcc/DEV-PHASE
+echo 'Amazon Linux %{version}-%{gcc_release}' > gcc/DEV-PHASE

I actually see the difference in:

$ gcc --version
gcc (GCC) 11.3.1 20220421 (Amazon Linux 11.3.1-2)

Yes, it is printed and also is what determines the presence and value of the
GNUC_RH_RELEASE macro, which intentionally is meant to be defined to the %{gcc_release} value only for the Red Hat builds. We don't want to use Fedora or CentOS or Red Hat Enterprise Linux there, all those just inherit from the same snapshots as long as the distro is maintained.
I have no idea what Amazon Linux will want to do, if they just want to rebuild the Fedora -> RHEL/CentOS sources with the given NVR and perhaps add some %{release} suffixes, then it should also use Red Hat because that will tell people it is (practically) the same compiler.

Got it, thanks, Jakub. I'm going to mull this over, and explore the code a bit more.

But it looks like I'll update the PR to only update the bug url and leave the vendor bit alone. I'll do this in a couple weeks' time.

Thanks!

I'm not sure how vestigial __GNUC_RH_RELEASE__ has become in packages in the field. For those curious about the origin story, it's here: https://bugzilla.redhat.com/show_bug.cgi?id=165728#c19

I would hope that most of the features that were backported in Red Hat's gcc vendor branch (necessitating a compile time check other than a conditional based on the GCC version number) are now in common use through upstream GCC releases, and that these backported features are less frequently introduced in modern times. Some examples of what you can find in the field are:
https://sourceware.org/git/?p=systemtap.git;a=blob;f=testsuite/sys/sdt.h;h=985c0a6c96d2369275f97a3c7d091c51c76b59ec;hb=HEAD#l102
https://github.com/rlaager/docsis/blob/master/configure.ac#L183

And, of course, the use of __GNUC_RH_RELEASE__ has sometimes been quite unpopular... https://lore.kernel.org/all/20090911205915.GA19494@bombadil.infradead.org/

That said, let's assume that __GNUC_RH_RELEASE__ still provides some utility. If so, downstream distributions need to be mindful of the semantics. It makes sense for Red Hat's vendor branch of GCC to identify as "Red Hat %{version}-%{gcc_release}'", and for downstream rebuilds to leave %{gcc_release} untouched.

Let me ask an unrelated question as well - why doesn't Fedora use the upstream branch instead of using the vendored branch?

I think that the question is orthogonal to this particular PR. From my perspective (which is my own), it is the same reason that Fedora doesn't ship a "vanilla" Linux kernel. Shipping off a downstream branch makes it easier to cherry-pick changes and improvements from upstream.

This introduces divergence in the bugs/features relative to the upstream releases, so I think it is a good practice to clearly identify the downstream release in some way for humans (e.g., in the --version output) and for programs (e.g., with __GNUC_RH_RELEASE__).

I get that - I suppose my question is more on the lines of "why use an upstream git.gcc.org vendored branch vs reference an upstream release branch, and maintain patches in the srpm, like other packages do".

That's perhaps documented somewhere I've not seen yet.

Using dist-git to maintain text diffs against upstream, and manually add and remove those text files from dist-git and from the spec file is a pain. Managing that in a git branch that actually tracks upstream is far smoother.

When a patch that has been backported to the vendor branch makes it into the upstream branch, a simple git merge will update the vendor branch, and Git realises the backported patch is already there, and it Just Works. With dist-git when you update to a new upstream version the local patches fail to apply, and have to be manually dropped from dist-git.

When the person maintaining the Fedora package in dist-git is also the person doing upstream work, and so already working in the upstream git repo, it's just unnecessary friction to divide that work into two places.

tl;dr adding a second level of git repo to tracks changes relative to an upstream git repo is silly.

rebased onto ba511be

2 months ago

Updated commit to drop the vendor change, and only update the bugzilla URL.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci

Metadata