Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
However, shoehorning X-is-X to apt for replacing alternatives is a very unoptimal (and even backwards) approach, because it’s not only for simple applications. Some of the daily alternatives I see are:
- x-www-Browser
- java (and the whole toolchain)
- editor
- vi
- pager
… The list goes on and on.
Alternatives provides a very elegant and usable way for handling multiple installed applications. Yet it adds a bit of packaging overhead, but it’s not that complicated, and is one of the neat parts of Debian.
I think it’s fine as-is, and it’s an essential part of machinery for Debian. If there are some shortcomings, which I failed to bump into while working with it, it can be improved, but I’m very against of its removal.
Cheers,
Hakan
> On 24 Dec 2023, at 12:06, Gioele Barabucci <gioele@svario.it> wrote:
>
> On 24/12/23 08:54, Alastair McKinstry wrote:
>>> While we are on the topic of alternatives, I hope to see the maintscript-based /etc/alternatives paradigm deprecated in favor of the package-based X-is-X paradigm introduced by `python-is-python3`.
>>>
>> They have different use-cases. alternatives allows for co-installability (and importantly - co-"buildability" with dependencies). the X-is-X guarantees essentially the opposite.
>
> I don't see X-is-X as a different use case when it comes to applications: both gnupg and sq-chameleon-gnupg could be installed at the same time.
>
> 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 other package and use /usr/bin/gpg-sq. The only Conflicts: here would be between gpg-is-gnupg and gpg-is-sq-chameleon.
>
> Regards,
>
> --
> Gioele Barabucci
>
Reply to: