-1 since I don't see much point in this. If we are going to be more open to such changes, we should develop consistent way of doing this. This came up some time ago in python2/python3 debates and how to deal with alternatives..

-1

-1

I'd like us to rely less on alternatives, not more. Doing this for core functionality like /usr/bin/cc doesn't sound like a good idea to me, and the benefits are small.

+1

I disagree with the comments above. I think there is merit to having cc and c++ be links managed by alternatives (or some other mechanism). It's easier to set up test environments or development environments using clang for more robust testing or for environments that want to default to something other than gcc. It also helps keep Fedora more flexible should we need to adjust what our default C and C++ compilers are at some point.

I will agree that alternatives as implemented is not necessarily the best solution, but it's established and works. I have confidence that Fedora can improve on that and offer something similar. Starting with cc/c++ would be a good idea, IMHO.

To be clear, I think that all the benefits described in the proposal are achievable without alternatives.

I'm fine with this, +1.

Basically what @dcantrel says, even though I think people should rely in env vars in most cases. I don't see this causing any harm and I actually think alternatives work well.

+1 too.

I'm not too happy about more alternatives use (because of more scriptlet use), but we're not getting rid of alternatives, so this is a weak argument.

And what @psabata said: this shouldn't cause harm. Also it will make some specific cases easier.

My take against this is:

Our guidelines say: "Alternatives MUST NOT be used when ... end users will care which variant they are using. If a non-root user would gain value by switching between the variants then alternatives MUST NOT be used."

That is the case here. And I don't think this satisfies an exception to that rule (one I agree with).

@churchyard FESCo policy is above the packaging guidelines, and we can approve something that isn't covered by the guidelines.

That said, I think those guidelines made sense when we were mostly thinking about large multi-user systems. Right now it seems totally appropriate to e.g. create a container (or a mock chroot or another specialized installation), with clang as the "system compiler". And the same applies to other tools which are not drop-in replacements, but may still be substituted with the expectation that the system will not break. (To clarify that last part: e.g. if /bin/sh was substituted with /bin/dash, the system might not even boot. But a compiler or a linker may be substituted and all packages should still function fine.) I think FPC should explore changing the guidelines to allow such cases too.

FESCo policy is above the packaging guidelines

I think that at least we should acknowledge that we are approving an exception.

I think FPC should explore changing the guidelines to allow such cases too.

I am not sure, but if we do, I'd rather have that than an exception for cc only.

Scheduled for the next meeting.

@tstellar, if you can attend it would be great. The meeting is on #fedora-meeting-1, Monday, 1500 UTC.

@tstellar

On the change page it says:

CI tests will be added to the gcc package to ensure that /usr/bin/cc and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when installed. There will also be a CI test added to the clang package to ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when clang is installed.

Are there going to be tests for clang to check that it works when enabled as an alternative?

Can you give couple of use cases/examples, where clang will be used as a drop-in replacement, which we are going to support?

On the minus side:

clang and gcc are definitively not interchangeable, there are many flags specific to gcc, and probably as many specific to clang.

On the plus side:

From a developer point of view, if use cc, I assume that may code is independent of the actual C compiler, while if I specifically use gcc or clang, I kind of state « my code is specific to a compiler ». That's why like the added value of the added cc command.

From a maintainer point of view, if I decide to use cc as a compiler I clearly state « I don't have any clang-specific or gcc-specific code ». That's not the topic of that proposal though, just a personal thought.

So basically a +1

@tstellar
On the change page it says:

CI tests will be added to the gcc package to ensure that /usr/bin/cc and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when installed. There will also be a CI test added to the clang package to ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when clang is installed.

Are there going to be tests for clang to check that it works when enabled as an alternative?

Yes, I can do that. I'm going to base the gating tests off of the ones I wrote for lld, which are here:
https://src.fedoraproject.org/rpms/lld/blob/master/f/tests/ld-alternative/runtest.sh
and I can add a few simple compile tests for clang as well.

Can you give couple of use cases/examples, where clang will be used as a drop-in replacement, which we are going to support?

By support do you mean that if someone sets /usr/bin/cc to clang and then it doesn't behave like gcc, that we would treat that as a bug in clang? If so, that's not what I had in mind. The goal is just to give users the option to set clang as the default and then what they use it for is up to them.

Approved (+6,2,-1) in today's meeting