[systemd-devel] documentation and required version

[Reindl Harald]

Am 30.07.2014 17:31, schrieb Zbigniew Jędrzejewski-Szmek:
> Some of our man pages in section 3 partially have history, see e.g. [1].
> I think having such information is very useful, but keeping it accurate
> is harder then it might seem at first. For example look at
> SocketUser/SocketGroup settings. They were added in systemd-214, but
> then were backported to 208-stable and 204-stable, and appeared in
> Fedora in a 204 update has Fedora 19 has been out for more than an a
> year [2]

the distribution backports don't matter in that context

the important information is "feature sounds cool, what
systemd version do i need at least" with that i know how
how my plans have do look like - grab if there is a backport
is a different story, users need to know "works on F20, F21
but not on F19 and RHEL7"

options introduced with 208 as example are considered for
my own rpm packages after the last machine is on F20 and
if "PrivateDevices" would be available on F20 i would even
give priority the F20 migration of our infrastructure

> It turns out that in this case man pages distributed with
> the system are a more accurate source of information then anything
> that could be included by upstream. So I'd be happy to merge patches
> which judiciously add history for manpages which describe API changes
> (i.e. section 3), but in general I don't think we have the man power
> to fully describe full history of all settings in systemd

wrong way around - don't think that complicated
somebody wrote that text below, see my fixed version at the end

*now* it is a mess and likely nobody will be able to fix the past
*but* for new options "Introduced with systemd-XXX" would be a no-brainer
_____________________________________________

RuntimeDirectory=, RuntimeDirectoryMode=

Takes a list of directory names. If set, one or more directories by the specified names will be created below /run
(for system services) or below $XDG_RUNTIME_DIR (for user services) when the unit is started, and removed when the
unit is stopped. The directories will have the access mode specified in RuntimeDirectoryMode=, and will be owned by
the user and group specified in User= and Group=. Use this to manage one or more runtime directories of the unit
and bind their lifetime to the daemon runtime. The specified directory names must be relative, and may not include
a "/", i.e. must refer to simple directories to create or remove. This is particularly useful for unprivileged
daemons that cannot create runtime directories in /run due to lack of privileges, and to make sure the runtime
directory is cleaned up automatically after use. For runtime directories that require more complex or different
configuration or lifetime guarantees, please consider using tmpfiles.d(5). Introduced with systemd-214

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140730/8478cc27/attachment.sig>