On Fri, Feb 05, 2021 at 10:16:14AM +0100, Lorenzo Puliti wrote: > Short answer: > Given that this is an alternative implementation for creating system users > related to an alternitive init system, and given the last GR results, it > make sense to drive the development of this package in a way that shift the > burden from Debian infrastructure and contributors to this package > maintainance, > whenever this is possible.
While we tend to like diversity, diversity in tools and interfaces comes at a cost. For example, cdbs is being faded out with reason. We're slowly moving the archive to a mostly debhelper-only ecosystem, because this sort of uniformity really makes things easier. The same holds for methods to create users. I strongly think that there should be one and only one way to create users and dh-sysuser isn't that one. Not because dh-sysuser would be technically inferior, but because it isn't popular. > Following the last GR, the overall state of 'creating system users' in Debian > is getting messy, currently we have It is messy, but at the same time, it recently got a little less messy than you pictured it. > * systemd-sysusers [systemd package]: > this is destructive on systems with an alternative init system, as > installing > systemd package will likely remove your Desktop Environment (due to > conflict with > elogind). This was one of the reason for the existence of dh-sysuser at > least > at the beginning You need to be a little more precise here. Please distinguish "systemd-sysusers, the interface" and "systemd-sysusers from the systemd package". Of course we do want to avoid the latter kind in dependencies for the reasons you give. However, the former actually makes sense and is not destructive, because there is another provider: > * opensysusers: > in Debian only since 2020; i'm doing some QA maintainance on it to allow > it's inclusion > in Bullseye. Supposed to work fine with alternative init systems, possibly > also with > systemd although this setup is not tested (and not sure someone is > interested in this) I think opensysusers should actually conflict with systemd to avoid having to test whether it cooperates. Why would you want to install opensysusers together with systemd? However, using dh_installsysusers will nicely allow using opensysusers as an implementation thus removing the "destructive on systems with alternative init systems" part while at the same time leveraging user descriptions that a number of upstreams include these days. dh-sysuser does not provide the same value here, because it is not readily available on e.g. Fedora. > * dh-sysuser: alternative declarative interface to handle creation and > removal of > users; known to work both with systemd and alternative init systems. > It's part of the runit infrastructure. It is declarative on a source package layer, but not declarative on a binary package layer. The latter would be important. > * systemd-standalone-sysusers [ future package ] > currently does not exists, not sure when it will, but has been discussed > in TC list > and some other bug too. Will work fine for alternative init systems. > Not sure if it will work on BSD port, wich is relevant for runit The standalone package will not happen. Consider opensysusers to be the standalone one. > As of my personal efforts: > I plan to stop doing QA on opensysusers if the standalone package from > systemd proves to > works fine on all cases that I care (including BDS port). At that point > someone else steps > in for opensysusers or the package will end up removed (or limited to BDS > port). > I don't plan to drop dh-sysuser soon as I may need it for runit future > development. I think you should rethink this. The standalone one will not materialize. Maybe you can refocus your effort into opensysusers? It'll be even easier on your side: The dh-sysuser counterpart is maintained inside debhelper. You only get to maintain the sysuser-helper counterpart opensysusers. Even better, you avoid forcing sysuser-helper on systemd systems and thereby avoid accidentally breaking those systems or taking blame for any breakage (whether caused by you or not). You can fully concentrate on the non-systemd part you are interested in. > It's declarative and it parses a file in the source. It would be declarative if the sysuser file would be installed into the binary package. > It allows me to fix things uploading a new version of sysuser-helper, > without the need to rebuild the affected package from source. This also holds for sysusers.d / opensysusers. > It's probably able to handle many kind of transition without requiring > coordination form others maintainers (I guess I will find out soon if it > works as expected with the Merged-usr transition). Such coordination would be very useful to avoid fragmentation. > Also (looking at the patch from #981799) I don't see a clear advantage > of systemd-sysusers in simlpifying syntax of rules or other files in the > /debian directory. That's not the goal. The goal is to avoid fragmentation. If the technical details are similar enough, preference should be on the most popular interface to reduce the transition effort. > One notable difference is that dh-sysuser parses on buildtime while > systemd-sysusers parses on runtime, but for Debian I'm not sure what can > be the advantage of one approach versus the other. Yes. The latter can be made to work with dpkg triggers in principle. dh-sysuser cannot. Thus dh-sysuser is a roadblock in making packaging more declarative (i.e. lacking maintainer scripts). > I plan to keep this bug open for the next release cycle so there is time > for people to highlight bug or other problems with this package. I tend to prefer actionable bugs, but so be it. Thank you for honestly considering my fundamental criticism. Much appreciated. Helmut
