https://bugzilla.redhat.com/show_bug.cgi?id=1983416 --- Comment #5 from Robert Scheck <redhat-bugzilla@xxxxxxxxxxxx> --- (In reply to Björn Persson from comment #4) > 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? Yes, your understanding is correct. > 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? Hm...good question. I guess it was too late at night, when I thought it would be clever. Thus I'll remove that. > 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.) Good point, I'll update that accordingly. > > 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. I thought that would be obvious, but I can indeed do so. > 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. Do I understand you correctly that you would be okay with this? gcc-gnat: /usr/bin/gnatgcc (binary) gcc-objc: /usr/bin/gobjc (binary) gcc-objc++: /usr/bin/gobjc++ -> gcc-gobjc (symlink) Because as per https://docs.fedoraproject.org/en-US/packaging-guidelines/#_duplicate_files the other approach doesn't seem to be allowed anymore but I would like to avoid a separate gcc-epel binary package increasing the complexity while only saving ~ 1.5 MB more in the end in a less common usecase. Is there currently something else to correct or discuss before I update the (large) SRPM? -- 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
