Change proposal seems straightforward to me. Three questions:

1) I do not see a mention of updating Fedora packaging policy regarding packages that need to link with clang libraries. I think that should be included here so future packages have guidance.

2) How would this be implemented for package maintainers? One or more macros in RPM or a set of steps to change spec files? Both?

3) Is there value to creating a rawhide gating test that can fail a build if it does not link with libclang-cpp.so per the change proposal? Seems like it would be easy to implement as a script.

I think we are talking only about modifying clang 10+, right? You are not going to apply this to clang9.0 package?

1) I do not see a mention of updating Fedora packaging policy regarding packages that need to link with clang libraries. I think that should be included here so future packages have guidance.

I don't think this needs to be in the guidelines. This is more about how to use clang in the upstream buildsystem.

2) How would this be implemented for package maintainers? One or more macros in RPM or a set of steps to change spec files? Both?

No macros I believe. Upstream buildsystem either needs to be patched or switched to a "compat" version of clang.

3) Is there value to creating a rawhide gating test that can fail a build if it does not link with libclang-cpp.so per the change proposal? Seems like it would be easy to implement as a script.

I don't think there is anything to test. The package either builds or it does not, that's it :)

If you are going to do this change only for clang10+, then I'd merge this change with #2304. But this is up to you :)

I think we are talking only about modifying clang 10+, right? You are not going to apply this to clang9.0 package?

Correct, I would only make this change for clang 10+.

2) How would this be implemented for package maintainers? One or more macros in RPM or a set of steps to change spec files? Both?

No macros I believe. Upstream buildsystem either needs to be patched or switched to a "compat" version of clang.

Right, no macros, just patching of upstream buildsystems.

3) Is there value to creating a rawhide gating test that can fail a build if it does not link with libclang-cpp.so per the change proposal? Seems like it would be easy to implement as a script.

I don't think there is anything to test. The package either builds or it does not, that's it :)

Yeah, the old libraries will be completely gone, so libclang-cpp.so is the only thing you could possibly link against.

If you are going to do this change only for clang10+, then I'd merge this change with #2304. But this is up to you :)

Ok, my thinking was that since I have to convince package maintainers to carry an extra build system patch, it might be useful to have a separate change request so I can make a better argument about why we should do this.

Correct, I would only make this change for clang 10+.

Could you please document that on the change page?

+1

Correct, I would only make this change for clang 10+.

Could you please document that on the change page?
+1

Yes, I've just updated the page.

+1

+1

After a week, this is APPROVED (+3, 0, -0)

Late, but +1

Announced.