Hi Helmut, thanks for your report!
Il giorno mar 7 nov 2023 alle 18:07:56 +01:00:00, Helmut Grohne
<hel...@subdivi.de> ha scritto:
opensysusers diverts /bin/systemd-sysusers. systemd has moved this
file
to /usr/bin/systemd-sysusers in version 255~rc1-1. While this change
is
not visible in an installation, the diversion no longer matches it.
Thus
what ends up at systemd-sysusers now depends on the order of unpacks.
The diversion has become ineffective. This is a known problem category
and documented in DEP17[1] as P3.
Usually, the recommended mitigation for this kind of problem is
duplicating the diversion (M18) such that both /bin/systemd-sysusers
and
/usr/bin/systemd-sysusers are diverted. I'm attaching a patch for this
approach, but I think this is not the preferred solution for this
case.
I dug deeper as to why opensysusers would divert systemd-sysusers,
talked to systemd maintainers and Thomas Goirand and read about
#947847
in the process. Given this background, I believe that the use of a
diversion is not a good solution and this was echoed by the CTTE
decision, which declined to overrule and considered diversion a
mechanism for experimentation. Three years later and with two stable
releases including opensysusers I hope we are past the experimentation
phase. The diversion setup bears a significant downside: While the API
existing API of the sysusers interface is relatively stable, systemd
keeps adding features and when systemd calls systemd-sysusers it wants
to be able to rely on its latest features. A diverted systemd-sysusers
may not provide what is needed here. Looking deeper into policy
sections
7.4 and 7.5, the virtual package systemd-sysusers looks similar to
mail-transport-agent where each implementation
provides+conflicts+replaces mail-transport-agent. I think opensysusers
should do the same. Once doing so, the diversion (and thus this bug)
goes away entirely. The downside is that opensysusers and systemd are
no
longer coinstallable. I'm also attaching a patch for this.
I do agree with this reasoning. As mentioned in one of the old threads
about this, in my opinion it would've been better to have a general,
more restricted "sysusers" alternative command which could've been
provided by opensysusers and systemd-sysusers, and would be used by
things like dh_installsysusers and the like. Stepping into the
"systemd-" namespace without actually supporting all the features *and*
closely following new feature additions is asking for trouble. And,
since the upstream developers (i.e. the Artix Linux maintainers)
stopped development in favour of systemd-standalone-sysusers[1], I'm
now more inclined to change approach and drop diversions.
I caution that Thomas Goirand disagrees with this approach and
recommends that these packages remain coinstallable and that users may
choose the implementation. On the flip side, a user cannot choose to
have systemd as the provider of systemd-sysusers when opensysusers is
installed.
I get Thomas' point, and I'd really like if I could keep offering
opensysusers as a valid alternative to systemd-sysusers, but given its
current state I don't think it's reasonable to keep doing so,
especially considering that there's systemd-standalone-sysusers. One
use case which systemd-standalone-sysusers doesn't cover though is
support for non-Linux OSes, but to be fair opensysusers doesn't either.
I did start working on a POSIX reimplemetation of the sysusers concept
so that it could replace opensysusers entirely and also run on (the now
dead) Debian/kFreeBSD and also Hurd, but never actually finished it.
A possible compromise could be that opensysusers stops diverting
systemd-sysusers and installs the symbolic link without diversion such
that systemd becomes the preferred provider when coinstalled. It could
detect removal of systemd using file triggers and then reinstate the
link. Such a setup also requires little cooperation from systemd
maintainers, but it relies on an symbolic link that is completely
untracked by dpkg, so there is some fragility to be found here whereas
the conflict is conceptually simpler.
I'm not sure I follow, but choosing an approach which isn't tracked by
dpkg doesn't sound right to me.
In any case, something needs to be done here. The latest systemd
upload
now declares an unversioned conflict with opensysusers. It can become
versioned once opensysusers has addressed this bug in some way.
I want to fix this too, and I really thank you for the help. I'm
inclined to drop the diversions, but I'd first like to fully understand
the consequences (e.g. would something break for someone?).
Bye :D
[1]: https://forum.artixlinux.org/index.php/topic,1839.0.html
