> 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
Received on Fri Apr 12 2024 - 15:55:29 CEST