3:30 p.m.
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.
== Owner ==
* Name: Jeff Law
* Email: law(a)redhat.com
== 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.
== 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.
== 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