[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: llvm-defaults vs update alternatives



* Sylvestre Ledru <sylvestre@debian.org> [140622 00:50]:
> Currently, LLVM default binaries are managed by the llvm-defaults package
> (similar to gcc-defaults).
> To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
> provides symlinks /usr/bin/llvm-nm to the actual binaries.
> Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
> snapshot).
> 
> I saw various complains from users (example:
> https://bugs.launchpad.net/bugs/991493 ) to switch to the
> update-alternatives mechanism. This would allow a quick and global
> switch from a LLVM version to another.

update-alternatives gives the user a choice, which implies that you
can no longer rely on the one specific configuration you would have
chosen ('the recommended configuration').
This basically means that you must test with all possible
configurations (LLVM versions), including those that no longer exist
in a given distribution (users may keep old packages that provide
alternative options).

The pain we've seen in the ruby packages suggests that using
update-alternatives is a bad idea if you have a 'recommended'
choice, as it will change over time and (enough) installed systems
will not follow suit.

I'd strongly recommend against using update-alternatives for
llvm-config.

  C.
-- 
 ,''`.  Christian Hofstaedtler <zeha@debian.org>
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Attachment: pgp3Lmx1iTcii.pgp
Description: PGP signature


Reply to: