On Mon, Oct 23, 2023 at 1:23 AM Michal Suchánek <msuchanek@suse.de> wrote:
On Thu, Oct 19, 2023 at 12:53:50AM +0200, Aaron Puchert wrote:
Am 18.10.23 um 19:25 schrieb Michal Suchánek:
On Tue, Oct 17, 2023 at 12:40:20AM +0200, Aaron Puchert wrote:
[...] But I should probably migrate [LLVM] from update-alternatives to GCC-style hardcoded symlinks in the metapackage. Please don't.
The hardcoded links are the worst, especially in the cases when binaries are often added/removed. Could you elaborate what the issue would be? What I'm thinking of is having
Am 17.10.23 um 08:38 schrieb Michal Suchánek: the metapackage contain symlinks for all files in /usr/bin of the corresponding versioned package. So if llvm17 has /usr/bin/opt-17 (let's say we go with the major version only), then llvm = 17 would have /usr/bin/opt -> opt-17. Quite similar to GCC actually, except with more binaries (and man pages). And changing what the gcc links point to requires you .. to rebuild a
On Wed, Oct 18, 2023 at 12:59:05AM +0200, Aaron Puchert wrote: package. Pin it to specific revision that points to the version you want, if you find one.
And if you don't adapt the current one to point to a different version .. except that fails with ever-changing list of binaries.
And have one project per gcc version you want to build with, too.
So you're talking about usage in OBS, not in deployment? This is actually what worries me about the update-alternatives mechanism. Some packages want to build against older Clang versions, but use unversioned commands. This works as long as no other package (possibly transitively) requires a newer version for some reason. We've mostly been lucky until now, and the cases that I've seen were the other way around [1], but it's definitely fragile to require a package not to be there. (Just to be clear: we want to allow different compiler versions to coexist, so conflicts are not acceptable.)
In such cases I think the proper way is to tell the build system to use the versioned compiler, e.g. via CC=clang-V CXX=clang++-V (or similar for GCC), and not to twist the symlink. The symlinks should in my view point to the distribution default.
Which some build systems accept, and some don't.
Also you can build a package that links all binaries that clang-N provides into /usr/bin/clang-N or whereever and add this to your path.
Nonetheless, the alternatives tend to work reasonably well.
If it doesn't respect variables, then usually twisting the PATH variable in the build also can fix it. You'd do that by creating symlinks in the %build phase in an arbitrary directory, then prepending that directory to the PATH. It's a bit overkill, though. Fortunately, such a thing has been incredibly rare in my experience. I only encountered one package where that was needed, and I was able to figure out their build script to hack in support for variables instead. -- 真実はいつも一つ！/ Always, there's only one truth!