https://bugzilla.redhat.com/show_bug.cgi?id=1983416 --- Comment #4 from Björn Persson <bjorn@xxxxxxxxxxxxxxxxxxxx> --- (In reply to Robert Scheck from comment #3) > When looking to the RHEL 8 lifecycle, the upcoming rebase with RHEL 8.5 will > be likely the last one for RHEL 8. However, the plan is to perform in > general always the same rebases like RHEL (otherwise re-using the original > complicated spec file doesn't make much sense). If I understand you correctly, this means that any changes made to the RHEL package will make their way into the gcc-epel package, unless they break the Ada, Go or Objective C parts. Is that right? That makes this review much easier, because then I can pass over many things that, if they are considered problematic, should be fixed upstream rather than in this package. > They will be kept, because a) it is unclear whether a future rebase might > force another bootstrap situation (and be it just due to RPM package > build-time dependency issues) and b) there might be downstreams with other > architectures not covered by EPEL (armv7hl, i686), who might see themself in > the need of bootstrapping, too. This is reasonable, but I wonder about the "%if !0%{?epel_bootstrap}" conditions around the additions to the package descriptions. The instruction to use the other commands instead of "gcc" applies equally to bootstrapping packages and normal packages. Why did you conditionalize those paragraphs? > As long as _hardened_build is defined, any simple package rebuild doesn't > succeed for me. Not sure which tricks Red Hat used internally in their > private build system (maybe they built the package using another gcc > version). Then I think you should replace the comment "Hardening slows the compiler way too much." with one that mentions the build failure you saw. If you were adapting a spec file from Fedora, then I would say you should leave this part unchanged, but since you're introducing a change from the RHEL spec file, the associated comment should explain your actual reason for the change. (If it fails while building the GNAT tools, then it may be the same problem that we have with Ada packages in Fedora. The hardening tends to break linking of Ada programs.) > Which changes are you referring to exactly? The 'gcc(major)' one? Yes. > It relaxes > the strict dependency from same NEVRA to same N-major to avoid immediate RPM > package dependency conflicts in case of minor release bumps due to rebuilds > in RHEL and/or EPEL (it's quite unlikely that RHEL and EPEL will always be > on exactly the same NEVRA). That makes sense. Please write that in the spec. > Do you really think that these three copies cause harm? Build environments > never come in small, additionally I think it's a non-common case to really > have all three subpackages installed at the same time. Anyone who installs gcc-objc++ will have gcc-objc installed at the same time. /usr/bin/gobjc++ is a waste of bandwidth, repository storage space and developers' storage space. The harm is small but unnecessary. The file can be replaced with a link to gobjc at no cost. Merging gobjc with gnatgcc matters less. This would only save space on developers' workstations, and only if they install both gcc-gnat and gcc-objc, which may indeed be uncommon. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
