#2409 F34 System-Wide Change: CompilerPolicy Change
Closed: Insufficient data 3 years ago by bcotton. Opened 3 years ago by bcotton.

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.

Note this change is only for compiler selection. It does not change existing policies WRT runtime library selection, linker selection, debuggers, etc.


@jlaw would be nice if you could make links clickable again as they are in the original template though :)

Targeted release: Fedora 33
Name: Jeff Law
Email: law@redhat.com

these ones

-1. There's no proposal of how the guidelines should be updated.

There's no proposal of how the guidelines should be updated.

Having a complete change done before approving it is not mandatory. The change contains all necessary info that should be used for updating packaging guidelines. Writing those is just matter of a few hours so I don't think we should block on that.

This change proposal is only a policy update, with no other technical changes. I think it's marginally fair that some semblance of a proposed text would be useful for approving or declining the change.

I think it's marginally fair that some semblance of a proposed text would be useful for approving or declining the change.

I think so as well.

The summary has significantly different emphasis than the description part:

compiler selection for Fedora follows the package's upstream preferences

vs.

This change allows packages to be built with whatever compiler the upstream project recommends/supports (so long as that compiler is in Fedora). [emphasis mine]

I like the second wording much more. I don't think upstream preferences need to be followed. In fact, I have seen various upstreams which have had a strong compiler preference caused by reasons irrelevant for Fedora. One such reason is that upstream development is done on a Mac. Or upstream just doesn't like gcc or is otherwise completely clueless in matters of software engineering. I'm completely fine with giving the maintainer discretion to switch the compiler, but I don't think we should recommend or imply that following upstream is always the right choice. Also, I think it should be fine to switch the compiler even if upstream doesn't say anything about the compiler, but when for some reason compiling with clang is easier or works better.

tl;dr: why not just say that "packagers may switch to a different compiler in Fedora if there are technical reasons to do so, in particular if the software compiles better with the other compiler"?

@ngompa makes a valid point. Even though this is a policy change, I think seeing a draft or at least the main points of that change is a reasonable request. As it is described now, I think it's a good idea. Some questions:

  • Is this just a policy change or will it also include some examples for packagers if they want to use gcc or clang in their spec file? Are there going to be macros used to make it more fill-in-the-blanks in spec files?

  • Can the compiler selection vary by architecture in spec files? Compile with gcc on this platform and clang on another? Do we care?

  • Is there any impact to packagers who don't make an explicit selection of C compiler in their spec files?

Metadata Update from @ignatenkobrain:
- Issue tagged with: meeting

3 years ago

@jlaw could you join us tomorrow @ 14:00 UTC at #fedora-meeting-2 on freenode to discuss this issue?

Metadata Update from @ignatenkobrain:
- Issue untagged with: meeting
- Issue assigned to law

3 years ago
  • ACTION: law to propose PR for the Packaging Guidelines and we will
    vote again once that ready. (ignatenkobrain, 14:12:46)

It's been nearly three weeks with no updates. This proposal does not seem to be time-sensitive (it can be shipped in an incomplete state), but it may be worth re-evaluating the status at this point.

I guess @law is busy with the binutils/ar/gcc issues...

Precisely. The LTO stuff is more time sensitive due to the mass rebuild, so that's where my focus has been.

This is a policy change and doesn't require any immediate action at the package level. It's not forgotten, but just lower priority.

We've talked about this briefly in this meeting.

https://meetbot.fedoraproject.org/fedora-meeting-2/2020-08-12/fesco.2020-08-12-14.00.html

The Change Checkpoint: Completion deadline (testable) deadline has passed for Fedora 33 and this has not yet been approved. Since it is a policy change, the target Fedora version is not that relevant here and this can be rebranded to Fedora 34 change.

Metadata Update from @churchyard:
- Issue untagged with: F33
- Issue tagged with: F34

3 years ago

@law is this still something that is on your radar ?

Metadata Update from @cverna:
- Issue tagged with: stalled

3 years ago

Not really. It really feels like it needs to move to an F34 proposal and we'll revisit once I propose the actual doc changes. I've been buried in F33/LTO wrap-up and other stuff.

Metadata Update from @bcotton:
- Issue untagged with: F34
- Issue set to the milestone: Fedora 34

3 years ago

@law is this still something you would like to achieve in F34 ?

@law should this still be considered for F34?

At this point, we should either defer this change again to F35 or close it and let @law resubmit when he's ready. I have no preference either way.

It's been months without any updates. I'm going to assume this proposal is dropped and will be resubmitted later if the owner desires.

Metadata Update from @bcotton:
- Issue close_status updated to: Insufficient data
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata