#2305 F32 System-Wide Change: Stop shipping individual component libraries in clang-libs package
Closed: Accepted 7 months ago by psabata. Opened 8 months ago by bcotton.

Remove the individual component libraries (e.g. libclangBasic.so, libclangAST.so, etc.) from the clang-libs package. Packages that depend on the clang libraries should instead link against libclang-cpp.so.


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.

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

Metadata Update from @churchyard:
- Issue tagged with: pending announcement

8 months ago

Metadata Update from @psabata:
- Issue untagged with: pending announcement
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

7 months ago

Login to comment on this ticket.

Metadata