summaryrefslogtreecommitdiff
path: root/man/systemd.unit.xml
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2015-11-12 19:21:47 +0100
committerLennart Poettering <lennart@poettering.net>2015-11-12 19:27:24 +0100
commitf32b43bda454a70ae23d6802605d41b26dc24ce2 (patch)
tree6c673526e557006c0337eb90a6dfc639c4208b2d /man/systemd.unit.xml
parent05c450966a08ff85fa8348e2fe41b722612fa3dc (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.xml20
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>