[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Terminology changes for update-alternatives



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 <https://lists.debian.org/debian-dpkg/2021/03/msg00002.html>. (This
is bug #884368.)

This has kind of blocked improvements as there was no desire to expand
their usage in other places, where depending on the context it would
imply more painful transitions being involved.

For debhelper, Niels decided to use for its declarative support the term
"Dependents", which while not a wrong term, I've always found it too
close to dependencies which we use in the packaging relationships context,
potentially adding to the concept overload/confusion, in addition of
being long, so I've had my reservations about switching to it.

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 and unrelated as a direct term.

(Primary/secondary do not seem to represent this well, and I have an
aversion to the leader/follower pair and they don't seem to fit well
here anyway.)

This is the list of words that I've been playing with:

  * dependent links  --depend  (covered above)
  * affixed links    --affix   (might not be ideal for translation?)
  * coupled links    --couple  (seems redundant given the dictionary
                                description)
  * attached links   --attach  (seems confusing? and long)
  * ancillary links            (too long)
  * accessory links            (idem)
  * subsidiary links           (idem)

  * annex links      --annex   (discarded due to git-annex confusion)
  * bound links      --bound/--bind
  * laced links      --lace    (cryptic?)
  * tied links       --tie

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?

Thanks,
Guillem


Reply to: