Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
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 <bluca@debian.org> wrote:
>
> On Sun, 24 Dec 2023 at 22:48, Stephan Seitz <stse+debian@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.
>
Reply to: