On Mon, Jul 15, 2019 at 01:24:06PM -0500, Jason L Tibbitts III wrote: > >>>>> "VO" == Vít Ondruch <vondr...@redhat.com> writes: > > VO> I just wonder what is the point of: > > VO> > https://github.com/systemd/systemd/blob/b0ca726/src/core/macros.systemd.in#L122 > > You include the configuration file in the source package and > that macro basically just expands it into the spec.
The general idea is that result of running systemd-sysusers should be idempotent. If systemd-sysusers is called from a scriptlet or not, and then is later called from the running system, no matter how many times, the same configuration is used and the result "on disk" is the same. To achieve this, the snippet is both installed on disk (a), and embedded into the scriptlet (b). There is a subtlety: the administrator is allowed to override sysusers configuration (the same as almost any other part of systemd configuration). Such overrides are obviously honoured when systemd-sysusers is run normally, but also when it is run from a scriptlet. To this end, the scriptlet macro tells systemd-sysuers to insert config (b) in the same priority order where (a) would be inserted. Another general systemd principle is that it should be possible to wipe /etc and /var and reboot, and things should "just work" as far as possible. systemd-sysusers will recreate users on reboot, so by installing the file on disk the package supports this mode of operation for that part. > I guess it just saves packagers from having to call systemd-sysusers > properly. Not exactly ;) > VO> Why should the file be stored on the FS, when it is expanded during > VO> build time (if I understand the scriptlet correctly). > > Well you could just bypass the macro and call systemd-sysusers > yourself with the raw data as part of the command. I don't see anything > that requires the file to exist in the filesystem at runtime. We install the file in the filesystem for the reasons listed above, but also to serve as documentation. It's a tiny file but it tells the administrator where the user came from. > Personally I do think the subpackage method has merit, but hiding it > behind macros (if we want that) would probably be complex. But > debuginfo/debugsource packages are done that way so it should be > possible. Yep, it's definitely worth exploring. Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
