On Fri, 05 Feb 2021 10:16:14 +0100 Lorenzo Puliti <plore...@disroot.org> wrote:
> Package: dh-sysuser > Version: 1.3.5 > Severity: wishlist > X-Debbugs-Cc: plore...@disroot.org > > Note: CC Helmut Grohne as he started the discussion, > CC Niels Thykier as he might want to say something here > > Helmut Grohne <hel...@subdivi.de>, from #981683: > > > Further development seems like a good idea. The package uses useradd > > instead of the policy-recommended adduser. Is there a good reason > > for doing so? The approach taken here entirely sidesteps the > > established and declarative sysusers.d format. Is there a reason > > for not cooperating with it? Niels Thykier is working a lot on > > removing maintainer scripts and turning them into declarative > > alternatives such as triggers. dh-sysusers works towards the > > opposite. Why? As far as I can tell, project consensus is that > > system users should not be removed on purge, but dh-sysuser does > > so. From my subjectively skewed perception, dh-sysuser has only > > created problems, not solved any. I acknowledge that this is not > > the whole picture. > > 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. > If dh-sysuser creates problem, then people affected need to report > bugs about that. There is nothing i can and i will do if i'm not even > aware of the existence of an issue [ this package had 0 bug reported > until the beginning of 2021]. I've already opened bugs for the > 'adduser'and the 'remove on purge' issues, but that's not the kind of > bugs we are talking about. > > Long answer: > > Following the last GR, the overall state of 'creating system users' > in Debian is getting messy, currently we have > > * 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 > * 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) > * 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. > * 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 > 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. > > > More about dh-sysuser: > > > doing so? The approach taken here entirely sidesteps the > > established and declarative sysusers.d format. Is there a reason > > for not cooperating with it? Niels Thykier is working a lot on > > removing maintainer scripts and turning them into declarative > > alternatives such as triggers. dh-sysusers works towards the > > opposite. > > I don't see it that way, maybe I'm missing something? > > It's declarative and it parses a file in the source. > It allows me to fix things uploading a new version of sysuser-helper, > without the need to rebuild the affected package from source. > 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). > 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. > 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. > > > 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. > > Regards, > Lorenzo > [resend as I forgot to add CC]
