Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
Hi, More metapackages will make transitions harder though, I believe we want to avoid that. In what way would transitions become harder? The alternatives system has "manual" and "automatic" modes for each group, these would probably correspond to "manually installed" and "automatically installed". The latter can only happen if there is also a "defaults" package that pulls in the metapackage we currently designate as default, and the "defaults" package must allow the dependency to be fulfilled by any of the choices. APT will prefer not to uninstall packages if it doesn't have to. As a result, any user will stick to whatever was default when they installed the package, even if they have not explicitly expressed a preference, until that option is no longer available -- the same happens with the alternatives system only in manual mode, which is an explicit choice -- and when it happens, the alternatives system will explicitly tell the user that their choice is no longer available and the setting has reverted to automatic mode. The only way to speed up a transition is to add an explicit hard dependency somewhere and override the user's choice -- which then adds an installation ordering constraint that might be the exact opposite of the order we want. Simon
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On Thu, 28 Dec 2023 at 03:01, Simon Richter wrote: > > Hi, > > On 12/28/23 04:28, Luca Boccassi wrote: > > > 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. > > More metapackages will make transitions harder though, I believe we want > to avoid that. In what way would transitions become harder?
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
Hi, On 12/28/23 04:28, Luca Boccassi wrote: 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. More metapackages will make transitions harder though, I believe we want to avoid that. Simon
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 wrote: > > On Sun, 24 Dec 2023 at 22:48, Stephan Seitz > 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. >
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On Sun, 24 Dec 2023 at 22:48, Stephan Seitz 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.
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 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 >
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
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? Sorry, this is bullshit. -100. Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
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
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On 23/12/2023 14:34, Gioele Barabucci wrote: On 22/12/23 00:40, Daniel Kahn Gillmor wrote: If you're asking about using /etc/alternatives or something like that to provide some sort of generic swapping capability, or a dpkg Provides:, such that /usr/bin/gpg on some systems would point toward the "chameleon", i would want to see some significant archive-wide testing done before we even consider inflicting that on our normal users. 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. This becomes key if we have two different approaches desired or needed simultaneously: eg the adios parallel I/O library builds for both openmpi and mpich variants of MPI; different variants preferred for different architectures. Regards Alastair McKinstry -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On Sat, 23 Dec 2023 at 18:43, Gioele Barabucci wrote: > > On 22/12/23 00:40, Daniel Kahn Gillmor wrote: > > If you're asking about using /etc/alternatives or something like that to > > provide some sort of generic swapping capability, or a dpkg Provides:, > > such that /usr/bin/gpg on some systems would point toward the > > "chameleon", i would want to see some significant archive-wide testing > > done before we even consider inflicting that on our normal users. > > 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`. > > In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while > sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the > user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the > distro-wide preference expressed setting the appropriate Recommends in > gnupg or sequoia-chameleon-gnupg). > > Regards, Yes, that would be very nice, all those moving parts make the installation/upgrade processes so unnecessarily difficult and error prone. It's a maintenance nightmare that I'd be very happy to stop having to deal with anymore.
Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On 17086 March 1977, Gioele Barabucci 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`. In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the distro-wide preference expressed setting the appropriate Recommends in gnupg or sequoia-chameleon-gnupg). Ugh no, and have tons of near-empty packages for no good reason and also make local admins life harder. -- bye, Joerg
Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)
On 22/12/23 00:40, Daniel Kahn Gillmor wrote: If you're asking about using /etc/alternatives or something like that to provide some sort of generic swapping capability, or a dpkg Provides:, such that /usr/bin/gpg on some systems would point toward the "chameleon", i would want to see some significant archive-wide testing done before we even consider inflicting that on our normal users. 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`. In this scenario gnupg will ship gpg as /usr/bin/gpg-gnupg, while sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the distro-wide preference expressed setting the appropriate Recommends in gnupg or sequoia-chameleon-gnupg). Regards, -- Gioele Barabucci
