LLVM PPA: Script source availability

[Matthias Klose]

On 2/21/22 16:24, Whisperity wrote:
> [Current workflow without update-alternatives and having to deal with suffixes]
> 
> S(ysadmin): *uploads newer LLVM release, suddenly clang-15 is the
> version available*
> U(ser): *tries to run commands from history or from scripts that have
> "clang-13", or purely "clang" in them*
> U: Why are my scripts not working, it keeps saying command not found?
> S: We updated versions, you need to replace it.
> U: *replaces in certain places only, because honest mistake, runs
> script, it fails after some hours of work*
> U: What?! *<curated list of expletives aimed at sysadmin>*
> S: *<curated list of expletives aimed at both apt/debian and the user>*
> U: *does some more replacing, hopefully not missing anything this time*
> *It worked.*
> 
> [With update-alternatives]
> 
> S: *installs new release, sets system-wide alternative to new version*
> S: *may or may not uninstall old version*
> U: *all scripts use "clang", "clang++", "ld.lld", whatever*
> U: *runs their scripts or commands to produce a new build*
> *It works. Everyone is happy.*
> 
> The default meaning of "clang" would as expected, I would of course
> want to stay the same, whichever version the distribution is at right
> now.

I think you are over-simplifying your preferred solution.

 - a user might not be aware of where your clang, clang++ symlinks
   are pointing to.
 - compilation breaks, because newer clang++ defaults to a
   newer c++ standard version. But where does it come from?
 - much harder to debug in bug reports which version actually
   is used.
 - clang/clang++ don't use shared libraries a lot, but in case
   of a version change, these are most likely not ABI compatible.
   You don't care for your use case, but others do.

If you are such convinced about the alternatives, and if you have
control over all development systems, why don't you install these
alternatives yourself? update-alternatives is not bound to packages.

>>>> For example, someone already mentioned Java there, and indeed (taken
>>>> from an Ubuntu 18.04.6 LTS system):
>>>>
>>>>> ╰─ update-alternatives --query java
>>>>> Name: java
>>>>> Link: /usr/bin/java
>>>>> Slaves:
>>>>>   java.1.gz /usr/share/man/man1/java.1.gz
>>>>> Status: auto
>>>>> Best: /usr/lib/jvm/java-11-openjdk-amd64/bin/java
>>>>> Value: /usr/lib/jvm/java-11-openjdk-amd64/bin/java
>>>>>
>>>>> Alternative: /usr/lib/jvm/java-11-openjdk-amd64/bin/java
>>>>> Priority: 1111
>>>>> Slaves:
>>>>>   java.1.gz /usr/lib/jvm/java-11-openjdk-amd64/man/man1/java.1.gz
>>>>>
>>>>> Alternative: /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
>>>>> Priority: 1081
>>>>> Slaves:
>>>>>   java.1.gz /usr/lib/jvm/java-8-openjdk-amd64/jre/man/man1/java.1.gz
>>>>
>>>> There were a lot of changes from Java 8 to 11 on the command-line
>>>> interface which makes the two incompatible. (Although most of those
>>>> are not everyday-used flags.)
>> Yeah, Matthias (who particpated to the discussions on launchpad) and I (at some point)
>> have been maintaining openjdk packages too.
>>
>> It also uses a similar approach to llvm-defaults:
>> https://packages.debian.org/buster/default-jre (and others)

The alternatives system for Java comes from these days when you wanted to
install the i386 client build on an amd64 system, mostly for compatibility with
browser plugins (all the openjdk binary packages are Multi-Arch: same).  These
days are gone. So maybe we should stop managing the java symlinks with
alternatives as well.

Matthias