(In reply to Richard Biener from comment #2) > That's then required in all clang7, clang11, clang13 and clang15? In the SP2 > codestream we also seem to have llvm9 and I can't see llvm13 so that's > possibly > only via the OBS sle-backports repository? Yes, llvm13 (and llvm14) is in Backports. I can take care of this. > I'll note I had issues with the Factory python3-clang conflicts/provides > switching from %python3_sitearch to something else so I reverted that > (but only for llvm17). Yes, that's fine. I mostly think about Factory when packaging and don't consider compatibility issues with Leap. This is one of those cases. (In reply to Richard Biener from comment #3) > The change for llvm15 seems to be just adding to clang_binfiles? The > alternatives stuff there is obfuscated by macros. Yes, adding to clang_binfiles and removing from the file list is the equivalent change. (https://build.opensuse.org/package/rdiff/devel:tools:compiler/llvm15?linkrev=base&rev=28) Obfuscation was not the intention. The binaries were duplicated a couple of times, and since almost every major update adds and removes binaries, and I always messed something up, I decided that having the list of binaries in one place is better. That's what you find in the beginning of the spec file plus a macro %lapply that applies another macro element-wise to a list. (Admittedly, the "list apply" is a bit of black magic, and I'd like to find a better way sometime.) As a nice side effect, this reduced the spec file by a couple hundred lines. (https://build.opensuse.org/request/show/995044) > IMO the even older llvm might be better dropped on update? Can't talk about the versions in SLE, but the versions in Backports are unfortunately still being used: $ osc whatdependson openSUSE:Backports:SLE-15-SP6 llvm13 standard x86_64 llvm13 : autofdo velociraptor velociraptor-client $ osc whatdependson openSUSE:Backports:SLE-15-SP6 llvm14 standard x86_64 llvm14 : gtkd ispc klee klee-uclibc ldc python3-pyside2 python3-pyside2:sle15_python_module tilix tvm Not sure to which extent these packages could switch to other versions. The klee maintainer has pinned to llvm14, although a wider range of versions should be supported. Maybe we can relax this. The issue with ldc in the past was bootstrapping, not sure to which extent that has been addressed.