Metapackage approach is not the same for many reasons.
First, I have seen Debian installations which doesn’t have internet access, but setup with many alternatives of the same application (e.g.: Java). Moreover, apt automatically purges its cache after a successful transaction. As I said in my previous message, many things from browsers to pagers are configured over alternatives subsystem, and this will create tons of headache over many edge cases. Lastly, a user may have sudo privileges for update-alternatives, to switch stuff around if things prove to be problematic (e.g.: again Java, compilers, etc.) without having package management privileges (e.g.: remotely managed developer workstation). Alternatives work fine as-is. Fiddling with it only open more can of worms down the line. It’s there for a reason to begin with. Cheers, H. Sent from my iPhone > On 27 Dec 2023, at 22:29, Luca Boccassi <bl...@debian.org> wrote: > > On Sun, 24 Dec 2023 at 22:48, Stephan Seitz <stse+deb...@rootsland.net> > wrote: >> >> Am So, Dez 24, 2023 at 10:06:09 +0100 schrieb Gioele Barabucci: >>> After the installation there would be no /usr/bin/gpg. Once the user >>> installs, say, ggp-is-gnupg then /usr/bin/gpg will point to >>> /usr/bin/gpg-gnupg. Users (and scripts) are still free to install the >> >> And if you want to change it, you have to download and install a new >> package (and remove another) instead of using a local command >> (update-alternatives) that doesn’t need an internet connection? > > if you want to activate a new alternative, you have to download a new > package that provides it anyway, so there's no difference. Subsequent > switches will use the cached package, and if you have issues > downloading a 3 kilobytes metapackage then just ensure the cache is > never cleared. >
