diff options
| author | Lennart Poettering <lennart@poettering.net> | 2015-11-12 19:21:47 +0100 |
|---|---|---|
| committer | Lennart Poettering <lennart@poettering.net> | 2015-11-12 19:27:24 +0100 |
| commit | f32b43bda454a70ae23d6802605d41b26dc24ce2 (patch) | |
| tree | 6c673526e557006c0337eb90a6dfc639c4208b2d /man/systemd.unit.xml | |
| parent | 05c450966a08ff85fa8348e2fe41b722612fa3dc (diff) | |
core: remove support for RequiresOverridable= and RequisiteOverridable=
As discussed at systemd.conf 2015 and on also raised on the ML:
http://lists.freedesktop.org/archives/systemd-devel/2015-November/034880.html
This removes the two XyzOverridable= unit dependencies, that were
basically never used, and do not enhance user experience in any way.
Most folks looking for the functionality this provides probably opt for
the "ignore-dependencies" job mode, and that's probably a good idea.
Hence, let's simplify systemd's dependency engine and remove these two
dependency types (and their inverses).
The unit file parser and the dbus property parser will now redirect
the settings/properties to result in an equivalent non-overridable
dependency. In the case of the unit file parser we generate a warning,
to inform the user.
The dbus properties for this unit type stay available on the unit
objects, but they are now hidden from usual introspection and will
always return the empty list when queried.
This should provide enough compatibility for the few unit files that
actually ever made use of this.
Diffstat (limited to 'man/systemd.unit.xml')
| -rw-r--r-- | man/systemd.unit.xml | 20 |
1 files changed, 1 insertions, 19 deletions
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index b4044f43ef..c61469b2e7 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -452,27 +452,9 @@ </varlistentry> <varlistentry> - <term><varname>RequiresOverridable=</varname></term> - - <listitem><para>Similar to <varname>Requires=</varname>. - Dependencies listed in <varname>RequiresOverridable=</varname> - which cannot be fulfilled or fail to start are ignored if the - startup was explicitly requested by the user. If the start-up - was pulled in indirectly by some dependency or automatic - start-up of units that is not requested by the user, this - dependency must be fulfilled and otherwise the transaction - fails. Hence, this option may be used to configure - dependencies that are normally honored unless the user - explicitly starts up the unit, in which case whether they - failed or not is irrelevant.</para></listitem> - - </varlistentry> - <varlistentry> <term><varname>Requisite=</varname></term> - <term><varname>RequisiteOverridable=</varname></term> - <listitem><para>Similar to <varname>Requires=</varname> and - <varname>RequiresOverridable=</varname>, respectively. + <listitem><para>Similar to <varname>Requires=</varname>. However, if the units listed here are not started already, they will not be started and the transaction will fail immediately. </para></listitem> |