Re: Terminology changes for update-alternatives

2023-01-29 Thread James Addison
On Sun, Jan 29, 2023 at 06:00:51AM +0100, Guillem Jover wrote: > I've been pondering about other options, and I think the concept that > seems to describe best the relationship is akin a planet and its moon > or satellite orbiting around it and being pulled along. But satellite > seems too long

Re: Terminology changes for update-alternatives

2023-01-29 Thread Russ Allbery
Justin B Rye writes: > if "primary/secondary" is no good there are variants like "major/minor", > but I think the one I'd have expected to be a front-runner is "main > link" and "subsidiary link", with the latter abbreviating to "Sublinks:" > and "--sub". leader/follower is the other option

Re: Terminology changes for update-alternatives

2023-01-29 Thread Justin B Rye
Julian Andres Klode wrote: >> I'd like to move away from the master/slave terminology used in >> update-alternatives for both the external interfaces (CLI options, >> output fields) obviously preserving backwards compatibility, docs >> and for all the internal code symbols. For the same reasons as

Re: Terminology changes for update-alternatives

2023-01-29 Thread Julian Andres Klode
On Sun, Jan 29, 2023 at 06:00:51AM +0100, Guillem Jover wrote: > Hi! > > I'd like to move away from the master/slave terminology used in > update-alternatives for both the external interfaces (CLI options, > output fields) obviously preserving backwards compatibility, docs > and for all the

Re: Terminology changes for update-alternatives

2023-01-29 Thread David
On Sun, 29 Jan 2023 at 16:01, Guillem Jover wrote: > I'd like to move away from the master/slave terminology used in > update-alternatives for both the external interfaces (CLI options, > output fields) obviously preserving backwards compatibility, docs > and for all the internal code symbols.

Re: Terminology changes for update-alternatives

2023-01-29 Thread Justin B Rye
Guillem Jover wrote: > I'd like to move away from the master/slave terminology used in > update-alternatives for both the external interfaces (CLI options, > output fields) obviously preserving backwards compatibility, docs > and for all the internal code symbols. For the same reasons as mentioned

Terminology changes for update-alternatives

2023-01-28 Thread Guillem Jover
Hi! I'd like to move away from the master/slave terminology used in update-alternatives for both the external interfaces (CLI options, output fields) obviously preserving backwards compatibility, docs and for all the internal code symbols. For the same reasons as mentioned in