Am Di., 10. März 2026 um 10:43 Uhr schrieb Nikita Popov <[email protected]>: > > > On Mon, Mar 9, 2026 at 1:39 PM Michael J Gruber <[email protected]> > wrote: >> >> Hi there >> >> Apparently, LLVM changed something in the python API even though their >> release notes seem to claim otherwise. Here's a failed scratch build >> of a rawhide commit which worked before LLVM 22 landed >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=143160960 >> >> Builds against other Fedoras work (until LLVM 22 lands there). >> >> This is unfortunate at this point in the release cycle. It's made >> worse by the fact that we do not ship python-clang compat packages. Is >> there a particular reason why not? > > > I believe the reason we don't ship python-clang in compat packages is that we > don't know how to do that correctly. Normally, all the compat packages are > shipped in /usr/lib64/llvmNN, so that would be something like > /usr/lib64/llvmNN/lib/python3.14/site-packages/clang for python-clang. But I > assume that wouldn't actually work because that's not the location where > Python packages are expected to be located? > > I tried to look at what some compat packages from the Python ecosystem do. > Looking at a package like python3-sqlalchemy1.4 it seems to just ship the > files in the same location as the normal package and conflicts with it. This > seems very fishy to me, and not really viable for us (as we'd have to > conflict across all present and future compat packages). >
First of all, those breakages should be caught before merging LLVM 22 between two freezes. Everything else is work-arounds. Indeed, if there's clang21 but no python3-clang21 then testing packages which build require python-clang is much more important than testing those which BR clang. As for the path: It depends on the goal - (when) does it make sense to have different LLVM versions installed in parallel? If the answer is "no/never" (which is the answer from a build requires perspective), then the standard path and conflicts are appropriate. If it's rather something to be installed on top and used on a case by case basis, then a package specific path seems appropriate. Users would need to set their PYTHONPATH to prefer those specific paths, and probably adjust other env variables or build scripts so that a versioned clang is used instead of the unversioned one. One could also rename the python package (module) itself and put it in the standard path, but this would require adjusting a lot of import statements (import foo21 as foo and such). In summary, I'd rather know what changed and how to fix it ;-) Michael -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
