Hi Helmut,
Thanks for following-up in this bug, and thanks for your patience.
Helmut Grohne <hel...@subdivi.de>:
> 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.
I've read this argument countless times. Here's my remarks.
If the API of this systemd component changes all the time, when it's
supposed to be used by our packages, then we'd better avoid
systemd-sysusers at all costs, and declare it as not useable in the long
run, because constantly changing. This would be a strong case for using
only opensysusers.
Lucky, that's as much as I know, *NOT* the case, and what you're
describing is hopefully just FUD. If that's not, please be explicit
explaining which part of the API of systemd-sysusers changed, or what
feature was added: I'd be very curious to know, and it'd be nice to be
able to add the missing feature in opensysusers.
If you cannot explain what's not stable in this API, or what feature was
added recently that is missing from opensysusers, then I would strongly
suggest stopping spreading this kind of fake news, and let other people
re-implement parts of systemd if they feel like it.
If this is only a theoretical point, that systemd-sysusers *MAY* one day
implement a new feature, then the thing that counts is if opensysusers
is able to implement it as well, in a timely manner, to be able to stay
compatible. If that's the case, then there's nothing to be afraid of.
So please care to explain...
That being said, I agree (and always did) that dpkg-divert was, and is
(still) wrong, and should be replaced by a better solution. That was my
point of view in the first place, and what I wrote to the tech-committee
a few years ago.
> 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.
I don't understand why we're not then using update-alternatives. It has
always been my idea to do so, and have systemd-sysuser having a higher
priority over opensysusers... What's the blocker? You wrote it has
issues with /usr-merge, why would it be the case, if we only do stuff in
/usr/bin?
Andrea Pappacoda <and...@pappacoda.it>:
> since the upstream developers (i.e. the Artix Linux maintainers)
> stopped development in favour of systemd-standalone-sysusers[
I wouldn't be scared of upstream being gone in the case of opensysusers,
as this is a quite simple component to maintain. Though it's entirely
your call.
Cheers,
Thomas Goirand (zigo)
