Package: libnss-myhostname
Version: 257.9-1~deb13u1
Severity: wishlist
See this commit:
https://salsa.debian.org/systemd-team/systemd/-/commit/a0e7eede9ba115500b0fbe79ce1107458683dc6c
If you installed libnss-myhostname before this change,
upgrading will leave you with the unintended order, e.g.:
hosts: files resolve [!UNAVAIL=return] dns myhostname
However a freshly-installed Debian 13 host will have intended order, e.g.:
hosts: files myhostname resolve [!UNAVAIL=return] dns
I think we should not try to fix this, because
1) dh-nss lacks a way to do it; and
2) maybe the local sysadmin intentionally changed it back to the wrong old
order.
Therefore I think we should warn via Debian.NEWS
(which pops up in apt-listchanges) so on upgrade,
sysadmins know to manually fix all their old systems.
I do not *know* if this difference "real" problems, but
I have some circumstantial evidence, see below.
On one affected system "sudo -i" hangs for decaseconds during network outages,
I think because sudo tries to look up the local hostname to match against
sudoers(5), and
myhostname can't answer until dns and/or resolve have timed out.
Note debian-installer traditionally puts a "127.0.1.1 hostname fqdn" entry in
/etc/hosts, but
other installation methods do not, e.g. mmdebstrap, e.g.
https://cloud.debian.org/images/cloud/trixie/latest/debian-13-nocloud-amd64.qcow2
Also the documentation inconsistently suggests only an unqualified hostname:
https://www.debian.org/releases/trixie/arm64/apds03.en.html#id5268
The affected system was a stable install (Debian 11, IIRC) that was then
upgraded oldstable->stable until it got to Debian 13.
i.e. the affected system was never running testing or sid (but IIRC was running
src:systemd from stable-backports).
