macros.systemd.in: add %systemd_ordering #3776

haraldh · 2016-07-22T06:55:44Z

To remove the hard dependency on systemd, for packages, which function
without a running systemd the %systemd_ordering macro can be used to
ensure ordering in the rpm transaction. %systemd_ordering makes sure,
the systemd rpm is installed prior to the package, so the %pre/%post
scripts can execute the systemd parts.

Installing systemd afterwards though, does not result in the same
outcome.

To remove the hard dependency on systemd, for packages, which function without a running systemd the %systemd_ordering macro can be used to ensure ordering in the rpm transaction. %systemd_ordering makes sure, the systemd rpm is installed prior to the package, so the %pre/%post scripts can execute the systemd parts. Installing systemd afterwards though, does not result in the same outcome.

haraldh · 2016-07-22T07:11:04Z

https://bugzilla.redhat.com/show_bug.cgi?id=1118740

poettering · 2016-07-22T11:28:32Z

Fedora policy prohibits creating deps from macros iirc, no?

Also, this appears to be very fedora specific, hence I think this should better be added to the fedora downstream version instead of upstream?

keszybz · 2016-07-22T13:31:23Z

Fedora policy prohibits creating deps from macros iirc, no?

The FPC people have hinted that they don't object to using macros anymore. The rationale for this wasn't very technical, more of the lines of "a macro will obfuscate the deps", which doesn't make much sense because macros and generators are use a lot.

Also, this appears to be very fedora specific

It really applies to any rpm based distro... The limitation is always the same: systemd must be installed in the initial transaction to preserve current semantics of how units are enabled. But this limitation is almost always satisfied.

My only comment about the patch is that we should have some docs how the macros should be used in macros.systemd file itself. The difference between %systemd_requires and %systemd_ordering is a bit subtle. But this can be done in a separate patch, so I'll go ahead and merge this, so FPC can hopefully move along with their process.

keszybz · 2016-07-22T14:03:49Z

Actually the prohibition of %systemd_requires was already removed: https://fedorahosted.org/fpc/ticket/600.

keszybz · 2016-07-22T14:14:49Z

New FPC ticket: https://fedorahosted.org/fpc/ticket/644.

At least since 1.1.17, pacemaker_remoted can stand for full-fledged PID1 hence it doubly does not make sense for its installation, e.g. in the container, to bring systemd in (it may be blocked by other means, but still). No need to modify anything about "%{post,...} remote" as "%systemd_{post,...}" are resolved to silent, non-fatail systemctl invocations. Also simplify apply-when-defined for the main package in a similar way already aplied. References: systemd/systemd@2424b6b systemd/systemd#3776

At least since 1.1.17, pacemaker_remoted can stand for full-fledged PID1 hence it doubly does not make sense for its installation, e.g. in the container, to bring systemd in (it may be blocked by other means, but still). No need to modify anything about "%{post,...} remote" as "%systemd_{post,...}" are resolved to silent, non-fatal systemctl invocations. Also simplify apply-when-defined for the main package in a similar way already aplied. References: systemd/systemd@2424b6b systemd/systemd#3776

At least since 1.1.17, pacemaker_remoted can stand for full-fledged PID1 hence it doubly does not make sense for its installation, e.g. in the container, to bring systemd in (it may be blocked by other means, but still). No need to modify anything about "%{post,...} remote" as "%systemd_{post,...}" are resolved to silent, non-fatail systemctl invocations. Also simplify apply-when-defined for the main package in a similar way already applied. References: systemd/systemd@2424b6b systemd/systemd#3776

At least since 1.1.17, pacemaker_remoted can stand for full-fledged PID1 hence it doubly does not make sense for its installation, e.g. in the container, to bring systemd in (it may be blocked by other means, but still). No need to modify anything about "%{post,...} remote" as "%systemd_{post,...}" are resolved to silent, non-fatal systemctl invocations. Also simplify apply-when-defined for the main package in a similar way already applied. References: systemd/systemd@2424b6b systemd/systemd#3776

At least since 1.1.17, pacemaker_remoted can stand for full-fledged PID1 hence it doubly does not make sense for its installation, e.g. in the container, to bring systemd in (it may be blocked by other means, but still). No need to modify anything about "%{post,...} remote" as "%systemd_{post,...}" are resolved to silent, non-fatal systemctl invocations. Also simplify apply-when-defined for the main package in a similar way already applied. References: systemd/systemd@2424b6bd7 systemd/systemd#3776

poettering added rpm needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer labels Jul 22, 2016

keszybz removed the needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer label Jul 22, 2016

keszybz merged commit 2424b6b into systemd:master Jul 22, 2016

macros.systemd.in: add %systemd_ordering #3776

macros.systemd.in: add %systemd_ordering #3776

haraldh commented Jul 22, 2016

haraldh commented Jul 22, 2016

poettering commented Jul 22, 2016

keszybz commented Jul 22, 2016

keszybz commented Jul 22, 2016

keszybz commented Jul 22, 2016

macros.systemd.in: add %systemd_ordering #3776

macros.systemd.in: add %systemd_ordering #3776

Conversation

haraldh commented Jul 22, 2016

haraldh commented Jul 22, 2016

poettering commented Jul 22, 2016

keszybz commented Jul 22, 2016

keszybz commented Jul 22, 2016

keszybz commented Jul 22, 2016