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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 29 Jan 2023 at 16:01, Guillem Jover <guillem@debian.org> 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.)

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.)

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?

Hi,

Just offering my perspective as a native English speaker, I think
that is what is being requested here?

"Tow" sounds inappropriate to me, like a mis-translation by someone
not familiar with the technical domain. My opinion is that I would
definitely not choose that.

I would use "primary" together with "alternatives" or "alternates".
No need to spend any more time thinking about it :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 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

I want to suggest root and leaf.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

[...]

I want to suggest root and leaf.

"Leaf" is a good idea - definitely an improvement on "slave" imagery!
"Root" isn't the only option for the converse; others include "trunk"
or "stem" (real-world root systems branch out in much the same way as
leaves do, though computer jargon mostly ignores this). Or then again
you could mix metaphors and have "main" versus "leaf".
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Justin B Rye <justin.byam.rye@gmail.com> 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 that came to my mind, and that I think captures the nature of the secondary links (that they follow the
configuration of the primary link). That's what I think tow is trying to
get at (and I agree that tow reads oddly in English, as a word that I
wouldn't expect to see in a technical context and for which the analogy is
not immediately obvious).

--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 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.)

If I understand the terminology requirements correctly, then the
situation is that a person selects one "docking port"[1] (choice among alternatives), and with that selection made, multiple corresponding
"latches" (symlinks) are aligned to the selection.

A similar -- albeit perhaps less standardized -- analogy could be
electrical plugs and sockets (where multiple pins are aligned to match
a selected wall socket).

(apologies for the lack of message-id in my reply here; this is the
second time I've apologized for replying without one to list(s) that
I'm not subscribed to.. so I should figure out a way to reply
in-thread soon)

[1] - https://en.wikipedia.org/wiki/International_Docking_System_Standard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)