Re: DEP 17: Improve support for directory aliasing in dpkg
Please excuse the volume of mails I am producing at this time, but I
still think this adds to the discussion.
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> I have a bad feeling about this. I think some dpkg maintainer warned us
> that diversions would break. Let's peek at his list again. He also said
> update-alternatives would be broken. I admit not having dug into this
> yet, but my gut feeling already is that update-alternatives will become
> "funny" as well though I guess we cannot fix update-alternatives by
> adding alternatives.
Sometimes, feelings can be wrong. I admit not having done much with
alternatives, so let me roughly summarize the relevant aspects and then
evaluate the aliasing effects.
Every alternative has an "alternative name". This name is the one inside
/etc/alternatives. When it refers to a binary in $PATH, usually that
binary name also is the name of the alternative. Consequently, it is
very unlikely for us to have a conflict on this name due to aliasing.
Every alternative also has "generic name", which is the primary path of
the symlink installed. This can be /bin/something or /usr/bin/something
or something else entirely. I looked through the various paths I could
find in alternatives and never found two distinct alternatives using
aliased paths, so this much will very likely go without problems.
I looked around for possible non-canonical paths in alternatives (by
installing lots of packages and discovered these:
* /bin/bsd-csh is shipped by csh and is provided as primary target for
the csh alternative
* /bin/csh is a generic name for the csh alternative
* /bin/ed is shipped by ed and is provided as primary target for the
editor alternative
* /bin/elvis-tiny is shipped by elvis-tiny and is provided as primary
target for the editor alternative
* /bin/more is shipped by util-linux and is provided as primary target
for the pager alternative
* /bin/ksh is a generic name for the ksh alternative
* /bin/ksh93 is shipped by ksh93u+m and is provided as primary target
for the ksh alternative
* /bin/mksh is shipped by mksh and is provided both as primary and as
slave target for the ksh alternative
* /bin/mksh-static is shipped by mksh and is provided both as primary
and as slave target for the ksh alternative
* /bin/mt is a generic name for the mt alternative
* /bin/mt-gnu is shipped by cpio and is provided as primary target
for the mt alternative
* /bin/mt-st is shipped by mt-st and is provided as primary target
for the mt alternative
* /bin/nano is shipped by nano and is provided as primary target
for the editor alternative
* /bin/nano-tiny is shipped by nano-tiny and is provided as primary
target for the editor alternative
* /bin/nc is a generic name for the nc alternative
* /bin/nc.openbsd is shipped by netcat-openbsd and is provided as
primary target and slave target for the nc alternative
* /bin/nc.traditional is shipped by netcat-traditional and is provided
as primary target and slave target for the nc alternative
* /bin/netcat is a slave link for the nc alternative
* /bin/rc is a generic name for the rc alternative and installed by
9base
* /bin/rksh is a slave link for the ksh alternative
* /bin/rksh93 is shipped by ksh93u+m and is provided as slave target
for the ksh alternative
* /bin/tcsh is shipped by tcsh and is provided as a primary target for
the csh alternative
* /bin/true is not shipped by uim, but installed as primary target for
the uim-toolbar alternative
* /lib/cpp is a generic name for the cpp alternative and installed by
cpp
* /lib/systemd/system/ipset.service is a generic name for the
ipset.service alternative
* /lib/systemd/system/iptables.service is a generic name for the
iptables.service alternative
* /lib/systemd/system/netfilter-persistent.service is shipped by
iptables-persistent and provided as primary target and slave target
for the iptables.service and ipset.service alternatives by
iptables-persistent and ipset-persistent respectively
* /lib/systemd/system/ip6tables.service is a slave link for the
iptables.service alternative
* /lib/firmware/regulatory.db is a generic name for the regulartory.db
alternative
* /lib/firmware/regulatory.db.p7s is a slave link for the
regulatory.db alternative
* /lib/firmware/regulatory.db.p7s-debian is shipped by wireless-regdb
and is provided as slave target for the regulatory.db alternative
* /lib/firmware/regulatory.db.p7s-upstream is shipped by wireless-regdb
and is provided as slave target for the regulatory.db alternative
* /lib/firmware/regulatory.db-debian is shipped by wireless-regdb and
is provided as primary alternative for the regulatory.db alternative
* /lib/firmware/regulatory.db-upstream is shipped by wireless-regdb and
is provided as primary alternative for the regulatory.db alternative
I think ideally, we'd want these to become canonicalized eventually. And
this is where things get ugly. There is three cases to consider:
1. Updating the generic name. This can only be done if coordinated by
all the packages updating the alternative together. There is a
significant risk to loosing the user selection when doing so. Also
users may programmatically (e.g. ansible/puppet) change alternatives
and we break that too. So I think it is best to leave these as is
eternally.
2. The link target for the generic name. Just changing this will add a
new alternative without removing the other one. So the old link
target would have to be removed. When doing that, user selection is
probably lost and in a similar way, we break users who do this
programmatically (e.g. ansible/puppet). So best leave this as is
eternally.
3. Link targets for slave links. As far as I can see, we can just
change these and on the next package update running
update-alternatives --install will work despite printing
update-alternatives: warning: forcing reinstallation of alternative ... because link group pager is broken
None of these seems convertible at ease and the third category has
basically no items, so I think we should probably just do nothing about
alternatives and let them continue to use non-canonical paths. As far as
I can see, that should just work. Does anyone disagree with that
judgement?
Helmut
Reply to: