Re: Terminology changes for update-alternatives
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
> in <https://lists.debian.org/debian-dpkg/2021/03/msg00002.html>. (This
> is bug #884368.)
[...]
> All of which I seem to find issue with. But finally the one that I
> came up with recently, seems somewhat satisfactory, as it is short
> and seems to represent the relationship adequately:
>
> * «tow links» or «towed links» (not sure what would be best)
> --tow (additional CLI option)
> «Tows:» or «Towed:» (additional output fields)
>
> So the pair could end up being «main link» and «tow link» or
> «towed link». For the fields I'm not sure either, which of «Tows»: or
> «Towed:» would be better in place of «Slaves:».
>
> (I've got a couple of branches with trials, that I can easily amend or
> create a new one replacing them automatically.)
>
> Do these sound good? Do you have other (better) suggestions?
It's a pity we can't just call them "linked"...
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".
"Tow" is interesting but runs aground on the shortage of recognisable
nouns for the concepts of tow-er and tow-ee. Then again if it doesn't
strictly need to be a noun, that opens up possibilities like "--with"
(or "--add", if they're "additional").
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: