#644 Allow %systemd_ordering to be used
Closed: Fixed None Opened 2 years ago by zbyszek.

People who build minimal container images have requested a possibility to have packages without the dependency on systemd. Current guidelines require a hard dependency on systemd, either by %systemd_requires macro or by specifying the requirement directly. Systemd upstream has added a new %systemd_ordering macro which relaxes the dependencies to only effect ordering of installation [1, 2]. Please amend the guidelines to allow this new macro to be used instead.

In a normal system, systemd (obviously) is used to actually start daemons, but also service enablement/disablement/presetting which is implemented through package scriptlets requires systemd to be installed before any package with service files. Thus, guidelines have required a hard dependency Requires dependencies. With the dependencies in the new %systemd_ordering macro, systemd is not pulled in by the package. If something else pulls in systemd in the initial transaction, which is the usual case, the results will be the same as before. If nothing pulls in systemd and it is never installed, obviously systemd cannot be used, so the enable/disable status of the service does not matter. If systemd is installed afterwards, in a separate rpm transaction, services which were installed previously will not be properly enabled.

Suggested text for https://fedoraproject.org/wiki/Packaging:Scriptlets#Scriptlets:

If a package is suitable for an alternative init system or e.g. container image, and does not require any of the systemd mechanisms e.g. to install UID, GID, or tmpfiles, it can choose to use the %systemd_ordering macro instead of the %systemd_requires macro.

[1] https://github.com/systemd/systemd/commit/2424b6bd716f0c1c3bf3406b1fd1a16ba1b6a556
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1118740

(The understanding is that people who build such containers will know that systemd should not be installed afterwards. We probably should make this explicit somewhere.)

I don't see a problem with this in general. I'm not entirely sure about the proposed language, though. The issue is that it mentions "alternative init systems" when we had to go through a bunch of work to actually ban the use of alternative initsystems in Fedora. I'd hate to have anyone think that we've gone back on that.

Can we describe the use case without mentioning alternative initsystems or even containers? I'm still unsure of exactly when this would be used. The language in the proposal makes me think that we would actually switch a number of packages over. We don't use the systemd UID/GID adding thing in Fedora, do we? That would just leave packages which have daemons but don't use tmpfiles.d.

You're right. I took that language from the original bug report, but it's not very clear. I'd remove "Alternative init systems" but keep "container images", because otherwise things become very vague. Maybe something like this:

"If a package is suitable for installation without systemd (e.g. in a container image), and does not require any of the systemd mechanisms e.g. to install UID, GID, or tmpfiles, it can choose to use the %systemd_ordering macro instead of the %systemd_requires macro."

This "container image" would be mostly docker containers, but not only so. It would also work with systemd-spawn --as-pid2, rkt, and probably others.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-08-11/fpc.2016-08-11-16.00.txt):

  • 644 Allow %systemd_ordering to be used (geppetto, 16:31:31)

  • ACTION: Allow %systemd_ordering to be used (+1:6, 0:1, -1:0)
    (geppetto, 16:47:42)

Note for tibbs: you planned to remove the bit about uid/gid because we don't have any policy on that atm.

It should be pointed out that (at least atm) this macro is only available in branched (F25) and rawhide. How should compatibility be handled with F23, F24, and possibly even EPEL7?



%if 0%{?fedora} >= 25

or will this macro be backported?

I'll backport the macro. There's nothing fedora-version-specific in it. We didn't do it before because we were waiting for this ticket to be voted.

Would you prefer that I write this into the guidelines now with the caveat that it only works on F25+, or would you prefer that I wait?

Also note that EPEL7-specific issues would simply be writteh into EPEL:Packaging which is not under the control of the packaging committee.

Please wait. It's a trivial update to systemd, and making it conditional is awkward and complicates the guidelines for no good reason.

Updates have gone stable a while ago, so the macro is available in all Fedora versions. Let's proceed.

Written up. Announcement text:

The systemd section of the scriptlet guidelines was updated to indicate situations where the %systemd_ordering macro may be used instead of %systemd_requires.

Metadata Update from @tibbs:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.