https://bugzilla.redhat.com/show_bug.cgi?id=1983416 Robert Scheck <redhat-bugzilla@xxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(redhat-bugzilla@l | |inuxnetz.de) | --- Comment #3 from Robert Scheck <redhat-bugzilla@xxxxxxxxxxxx> --- (In reply to Björn Persson from comment #2) > Is the plan to rebase this package on future RHEL packages as they are > released, or is this package a fork that will have its own development line > from this point? 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). > What do you plan to do with the bootstrapping bits after the package has > been built in EPEL? 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. > Could you comment on _hardened_build? Did you undefine it just because > Fedora does, or is there a better reason for that difference from the RHEL > package? 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). I however got this idea purely from the Fedora package (but the real intentions at Fedora for their change are unclear to me). > I think there should be comments explaining the changes to the dependencies. Which changes are you referring to exactly? The 'gcc(major)' one? 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). > Someone who installs all of gcc-gnat, gcc-objc and gcc-objc++ will get three > copies of the same file. I suggest to install the compiler driver once, as > /usr/bin/gcc-complete or /usr/bin/gcc-epel, make all the other names links > to that file, and include that file in the subpackages gcc-gnat and > gcc-objc. Packages can share ownership of a file when the file is identical > in the different packages. gcc-objc++ doesn't need to contain the compiler > driver because it pulls in gcc-objc. 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. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. _______________________________________________ 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
