681eb9cf2b
In particular, use /lib/systemd instead of /usr/lib/systemd in distributions like Debian which still have not adopted a /usr merge setup. Use XML entities from man/custom-entities.ent to replace configured paths while doing XSLT processing of the original XML files. There was precedent of some files (such as systemd.generator.xml) which were already using this approach. This addresses most of the (manual) fixes from this patch: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220 The idea of using generic XML entities was presented here: http://lists.freedesktop.org/archives/systemd-devel/2015-May/032240.html This patch solves almost all the issues, with the exception of: - Path to /bin/mount and /bin/umount. - Generic statements about preference of /lib over /etc. These will be handled separately by follow up patches. Tested: - With default configure settings, ran "make install" to two separate directories and compared the output to confirm they matched exactly. - Used a set of configure flags including $CONFFLAGS from Debian: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules Installed the tree and confirmed the paths use /lib/systemd instead of /usr/lib/systemd and that no other unexpected differences exist. - Confirmed that `make distcheck` still passes.
54 lines
1.7 KiB
XML
54 lines
1.7 KiB
XML
<?xml version="1.0"?>
|
|
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
<!ENTITY % entities SYSTEM "custom-entities.ent" >
|
|
%entities;
|
|
]>
|
|
|
|
<variablelist>
|
|
<varlistentry id='user'>
|
|
<term><option>--user</option></term>
|
|
|
|
<listitem id='user-text'>
|
|
<para>Talk to the service manager of the calling user,
|
|
rather than the service manager of the system.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry id='system'>
|
|
<term><option>--system</option></term>
|
|
|
|
<listitem id='system-text'>
|
|
<para>Talk to the service manager of the system. This is the
|
|
implied default.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry id='host'>
|
|
<term><option>-H</option></term>
|
|
<term><option>--host=</option></term>
|
|
|
|
<listitem id='host-text'>
|
|
<para>Execute the operation remotely. Specify a hostname, or a
|
|
username and hostname separated by <literal>@</literal>, to
|
|
connect to. The hostname may optionally be suffixed by a
|
|
container name, separated by <literal>:</literal>, which
|
|
connects directly to a specific container on the specified
|
|
host. This will use SSH to talk to the remote machine manager
|
|
instance. Container names may be enumerated with
|
|
<command>machinectl -H
|
|
<replaceable>HOST</replaceable></command>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry id='machine'>
|
|
<term><option>-M</option></term>
|
|
<term><option>--machine=</option></term>
|
|
|
|
<listitem id='machine-text'>
|
|
<para>Execute operation on a local container. Specify a
|
|
container name to connect to.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|