On 06/05/2020 12:09 AM, Igor Raits wrote: > On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/CompilerPolicy > >> == Summary == >> Fedora has historically forced packages to build with GCC unless the >> upstream project for the package only supported Clang/LLVM. This >> change proposal replaces that policy with one where compiler >> selection >> for Fedora follows the package's upstream preferences. > > Sadly some upstreams insist on clang just because they like it more, > without any technical reason. The question that comes to my mind: > Should we still try to convince upstreams to use GCC in such cases or > not? > > Also does this mean that Clang is now fully supported compiler by full- > time working people @ Red Hat in toolchains team that are also > contributing to upstream? Just curious if we will be able to "fully > support" people when we find bugs in the compiler. > > And also, does it mean that we will be following same pattern as with > GCC to test pre-release versions in rawhide, do the mass rebuild and so > on? > We have been packaging -rc1 release candidates of major Clang/LLVM releases in rawhide and plan to continue doing this. It's also possible we could package even early snapshots if this fits better with the Fedora release schedule, but this is not something we have done before. -Tom >> == Owner == >> * Name: Jeff Law >> * Email: law@xxxxxxxxxx > > Thanks Jeff for working on this! > > >> == Detailed Description == > >> The main goal here is to make selection of the compiler to build a >> package flow from upstream in an effort to preserve our development >> resources. In cases where there is no upstream the Fedora package >> maintainer should be allowed to make the compiler choice for the >> package. For packages where upstream does not have a strong compiler >> preference, we should (for now) stick with the status quo to avoid >> unnecessary churn. > >> == Benefit to Fedora == > >> This change allows packages to be built with whatever compiler the >> upstream project recommends/supports (so long as that compiler is in >> Fedora). Thus, Fedora package owners no longer need to spend time >> making a package work with GCC if the upstream project is using >> Clang/LLVM. > >> An obvious example is Firefox. Upstream, the Firefox project builds >> primarily with Clang/LLVM. Yet we force the Fedora package owner to >> find and fix issues building with GCC then either carry those custom >> fixes forward in Fedora or negotiate with upstream to get those >> changes upstreamed. While this process can be helpful in finding >> non-portable code, this is ultimately a poor use of the packager's >> time. > >> Additionally Fedora loses the benefit of the testing provided by >> other >> distributions where Firefox is compiled in the same way as the >> upstream project -- when issues arise the Fedora team must consider >> the possibility that the problem is due to using GCC instead of >> Clang/LLVM or the patches to make that possible. Again, this is a >> poor use of Fedora developer's time. > >> In the immediate term this change in policy only affects a few >> packages (Firefox, Chromium and perhaps a few others). The benefit >> will likely expand over time. > >> == Scope == >> * Proposal owners: >> Update the Fedora Packaging Guidelines to reflect the policy change. > > >> * Other developers: >> Developers working with packages where upstream builds with >> Clang/LLVM, but Fedora policy has forced the package to build with >> GCC >> should update their packages to build with Clang/LLVM, dropping all >> Fedora specific changes that were necessary to make the package build >> with GCC. > >> Firefox and Chromium are known to be impacted, there may be other >> packages. While there is no specific timeframe where this would need >> to be accomplished as the existing packages are already building with >> GCC, getting the conversion done earlier rather than later seems >> beneficial. Failure to identify all the impacted packages is not a >> catastrophic failure, we just fail to reap the benefits in the >> immediate term. > >> * Release engineering: [https://pagure.io/releng/issue/9503] (a check >> of an impact with Release Engineering is needed) >> I do not believe this change requires any coordination with release >> engineering. No mass rebuild is required. > >> * Policies and guidelines: >> Yes, the packaging guidelines certainly need to be updated for this >> feature. That can happen as soon as the exact text is agreed upon. >> Development work on packages such as Firefox or Chrome can happen as >> soon FESCO agrees to the change while the final packaging guideline >> text is hammered out. > > >> * Trademark approval: N/A (not needed for this Change) > >> == Upgrade/compatibility impact == >> This should not require any configuration changes or data migration, >> nor should it change existing functionality. > >> == How To Test == >> For packages where the compiler should change, the package owner will >> need to update the spec file and build the package with the new >> compiler. Once done, the package's testsuite should be run (if it's >> not part of the standard build process). > >> In general, I would think the standard Fedora QE work should be >> sufficient here, perhaps with a bit of additional attention to the >> affected packages. The graphical nature of some of the affected >> packages like Firefox and Chrome will make testing difficult on some >> of Fedora's architectures. > >> == User Experience == >> Users should not notice any change. > > I think this is not fully true because clang / gcc produce different > binaries in terms of size / performance. So just switching compiler in > some package may result in significat (hopefully not) performance gain > / drop. > > Also we probably should mention that -fstack-clash-protection is not > available in clang, so in theory binaries can be less secure due to > that. > >> == Dependencies == >> One the policy change is made a set of packages will need to be >> updated. Firefox and Chrome are known to be affected. There may be >> others. It seems like the Fedora package owners are in the best >> position to know if their package is affected by the policy change. > >> It is useful to remember that the packages as they exist today still >> work. Therefore if a package which should change is not identified >> now, it will continue to work. Similarly if the package owner does >> not have the time to implement the change right now, the existing >> package will continue to work. > > I think this should mention that annobin plugin should be prepared for > clang. > >> == Contingency Plan == >> The backup plan is trivial. We can keep the current policy in place. > >> If the policy change is approved, but a particular package has not >> switched to the upstream preferred compiler, the package can continue >> to build with GCC until the package maintainer has the time to make >> the change for their particular package. > >> Failure to convert any particular package should not create any >> downstream or distribution wide delays. > >> * Contingency mechanism: >> It seems like we could institute the policy change anytime we choose. >> But it also seems like once the policy change is in place, packages >> that are going to convert should do so before beta freeze. > >> * Contingency deadline: Fedora can ship with this feature in an >> incomplete state. >> * Blocks release? No >> * Blocks product? N/A > >> == Documentation == >> Several years ago Red Hat's tools team championed for Fedora policy >> to strongly >> discourage the use of LLVM/Clang for package building. Exceptions >> were made for >> packages that could only be built with Clang/LLVM: > >> https://docs.fedoraproject.org/en-US/packaging-guidelines/#compiler > > >> At that point in history Red Hat had no Clang/LLVM engineers or >> expertise. In >> fact, the LLVM packages were actually maintained by an engineer on >> the desktop >> team (they had a hard requirement for llvm-pipe, so they got to own >> the >> Clang/LLVM bits). The policy essentially was a risk management >> strategy for >> Fedora. > >> Times have changed and as a result we should revisit that Fedora >> policy. > >> The Red Hat tools team believes that LLVM/Clang and GCC should be >> considered equals from >> a Fedora policy standpoint. Selection of one toolchain over the >> should should be >> driven by the upstream project's preferences not by Fedora specific >> policy. > >> What that means in practice is that if the project upstream prefers >> Clang/LLVM, >> then Fedora should in turn be using Clang/LLVM to build those >> packages. As a >> concrete example, let's consider Chromium. > >> Chromium upstream has been building with Clang/LLVM for several >> years. >> Yet policy >> has forced Fedora package owners to shoulder a significant burden to >> make it >> build with GCC. Furthermore, Fedora does not get as much benefit at >> it could by >> forcing Chromium to be built with GCC since most other instances are >> built with >> Clang/LLVM. > >> By changing policy Fedora package maintainers no longer have to waste >> time trying >> to make Chromium build/work with GCC and Fedora gains additional >> "many eyes" and >> "many users" benefits by relying on the same tools to build Chrome as >> the >> upstream developers and other distributions. > >> Additionally, if an upstream project currently uses GCC, but switches >> to >> Clang/LLVM (or vice-versa), then the package in Fedora should switch >> in a similar >> manner. The only policy restriction should be that the compiler >> must >> exist in Fedora. > >> In some ways this means there is no "default" compiler for Fedora. >> The default >> is whatever the upstream project supports/recommends. However, there >> are >> probably many packages with upstreams that are ambivalent about their >> compiler >> choice. For those packages I would recommend we keep the status quo >> at the >> current time. For a package with a dead upstream, the Fedora >> packager should be >> able to select the compiler they want to use for the package. > >> == Release Notes == >> This change should not have any end user impacts nor does it strictly >> require a release note. However, a short release note could be >> written if FESCo or the development community thinks it would be >> useful. > > >> -- >> Ben Cotton >> He / Him / His >> Senior Program Manager, Fedora & CentOS Stream >> Red Hat >> TZ=America/Indiana/Indianapolis >> _______________________________________________ >> devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to >> devel-announce-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/devel-announce@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
