> On Alpine, s6-ipcserver is in a separate package because Alpine is very > careful about disk space, so much that they wanted me to make utmps > available without the bulk of s6. (Yes, I find this pretty hypocritical > given other decisions they make, but I was tired of arguing with them.) > > On RedHat, you will not have the same concern: s6 is a drop in the water > compared to the amount of disk space you need to boot anyway. So it does > not make sense to separate s6 from s6-ipcserver, and I suggest making the > utmps package depend on the s6 package anyway. > Ok, I will merge s6-ipcserver into s6 package.
> This is a separate question from running the [uwb]tmpd services under > s6-svscan or systemd. Both approaches have advantages. > > Running the utmps services under systemd: > - they start earlier > - you can make any systemd service depend on them > > Running the utmps services under s6: > - independence from systemd, can be portable anywhere > - shows an example of how to run a service under s6 > I would like to package an example service for s6. Could you suggest one? > >> 3. Run btmpd, utmpd, wtmpd as s6-rc service. Add two more dependencies: s6 >> and s6-rc. > > That option, on the other hand, isn't a good one. There is an argument > for running a s6 supervision tree under systemd, but there is little > argument for running s6-rc and having a parallel service manager ecosystem > - this probably adds more complexity than it's worth. (Unless it's for > transitional purposes, but transitioning Fedora out of systemd isn't > happening.) So, is s6-rc a good candidate for rpm package? I am preparing to build s6-rc package in next few days. > ... > > All of that being said, however, my opinion is that you *should not* > package utmps for Fedora. utmp management is a distro-wide decision: > the utmp database is unique and accessed by several components in the > system. Fedora uses glibc, and glibc has its own utmp implementation, > and all the existing Fedora packages expect utmp to be managed by the > glibc implementation. Adding utmps, and packages that will use utmps, > will introduce conflict, and break things. (The utmp databases won't > have the correct permissions, glibc will access the files directly > without the locking that utmps does and concurrent access will cause > file corruption, etc.) > > utmps isn't something that you can add like this and have some packages > depend on it and others not. It has to be a concerted effort by the whole > distribution, to decide if they switch to it or not. Alpine uses it > because musl doesn't provide a real utmp implementation; the transition > could be done incrementally without conflicting. glibc-based distros are > another story, a transition would need to be done atomically. And unless > you submit a proposal to Fedora and it is discussed and accepted by the > Powers That Be, it's not happening. Thanks for your suggestion, when I see the content of utmp-prepare and utmp-init, I have the same question: will this conflict with the existing utmp/wtmp service? Thanks for your detail response. Wang