I want to second this text, but have some questions. > diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst > index 0771346..3519d99 100644 > --- a/policy/ch-controlfields.rst > +++ b/policy/ch-controlfields.rst
> @@ -1020,6 +1022,118 @@ This field is automatically added to Debian source
> control files
> field may also be used in source package control files
> (``debian/control``) if needed in other situations.
>
> +.. _s-f-Rules-Requires-Root:
> +
> +``Rules-Requires-Root``
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Simple field that defines if the source package requires access to
> +root (or fakeroot) during selected targets in the :ref:`Main building
> +script: debian/rules <s-debianrules>`.
> +
> +The field can consist of exactly one of the following three items:
> +
> + - ``no``: Declares that neither root nor fakeroot is required.
> + Package builders (e.g. dpkg-buildpackage) may choose to invoke any
> + target in ``debian/rules`` with an unprivileged user.
> +
> + - ``binary-targets`` (default): Declares that the package will need
> + the root (or fakeroot) when either of the ``binary``,
> + ``binary-arch`` or ``binary-indep`` targets are called. This is
> + how every tool behaved before this field was defined.
> +
> + - A space separated list of keywords described below. These must
> + always contain a forward slash, which sets them apart from the
> + other values. When this list is provided, the builder must provide
^^^^^^ plural here, makes sense.
> + a `gain root command` (as defined in :ref:`debian/rules and
> + Rules-Requires-Root <s-debianrules-gainrootapi>`) *or* pretend that
> + the value was set to ``binary-targets``, and both the builder and
> + the package's ``debian/rules`` script must downgrade accordingly
> + (see below).
> +
> +If the package builder supports the ``Rules-Requires-Root`` field and
> +want to enable the feature, then it must set the environment variable
> +``DEB_RULES_REQUIRES_ROOT`` when invoking the package building script
> +``debian/rules``. The value of ``DEB_RULES_REQUIRES_ROOT`` should be
> +one of:
> +
> + * The value of ``Rules-Requires-Root`` if the builder can support
^^^^^ singular here. I find this ambiguous. I think you mean
to treat the list of values above as one variable by calling it singular
here, a suggested by the remark about space below.
> + that value. The builder may trim unnecessary whitespace used to
> + format the field for readability.
> +
> + * The value ``binary-targets`` if it cannot support the value of
> + ``Rules-Requires-Root``.
> +
> +A compliant builder may also leave ``DEB_RULES_REQUIRES_ROOT`` unset
> +or set it to ``binary-targets`` if it has been requested to test
> +whether the package it builds correctly implements the fall-back for
> +legacy builders.
> +
> +Remarks
> +^^^^^^^
> +
> +All packages and builders must support ``binary-targets`` as this was
> +the historical behaviour prior to the introduction of this field.
> +
> +Any tool (partiularly older versions of them) may be unaware of this
> +field and behave like the field was set to ``binary-targets``. The
> +package build must gracefully cope with this and produce a
> +semantically equivalent result.
> +
> +This field intentionally does not enable a package to request a true
> +root over fakeroot.
Apparently some details in the implementation are unclear to me, as I
don't get this statement if the example at the end includes a sudo
example. Isn't that a true root or is that not what you mean? Is only
$(su root) a real root (and why wouldn't that work)?
> +
> +Definition of the keywords
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +The keywords have the format ``<namespace>/<case>``, where:
> +
> + * ``<namespace>`` must consist entirely of printable ASCII characters
> + except for any whitespace and the forward slash (``/``). It must
> + consist of at least 2 characters.
> +
> + * ``/`` (between ``<namespace>`` and ``<case>``) is a single ASCII
> + forward slash.
> +
> + * ``<case>`` must consist entirely of printable ASCII characters
> + except for any whitespace. It must consist of at least 2
> + characters.
> +
> +These keywords define where the package build script ``debian/rules``,
> +or the tools called by that script, will need access to root or
> +fakeroot.
> +
> +In addition to the keywords defined in the next section, each tool or
> +package may define keywords within a namespace named after that tool
> +or package. The package or tool is considered to own that namespace.
> +
> +A tool may use the `gain root command` to do something under
^^^ a?
^^^^^^^^^^^^^^^^^ should this be linked to the
*section describing it? It drops out of thin air here.
> +(fake)root if and only if the tool defines an appropriate keyword in
> +its namespace, and the package lists that keyword in
> +``Rules-Requires-Root``.
> +
> +All tools must ignore keywords under namespaces they do not know or
> +own. A tool may emit a warning, or abort with an error, if it finds
> +unknown keywords in namespaces it owns, but it is not required to do
> +this for all keywords in the namespace.
> +
> +Provided keywords
> +^^^^^^^^^^^^^^^^^
> +
> +The following keywords are defined:
> +
> + * ``dpkg/target-subcommand``: declares that there exists a command
> + that the ``debian/rules`` file must run under (fake)root
> +
> + * ``dpkg/target/foo``: declares that the additional, package-specific
> + target ``foo`` (that is, not one of the targets specified in
> + :ref:`Main building script: debian/rules <s-debianrules>`) must be
> + run under (fake)root
> +
> +This list is intentionally incomplete. You should consult the
> +documentation of the tool or package in question for which keywords it
> +defines and when they are needed.
> +
> .. _s5.7:
>
> User-defined fields
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index e3b1981..214d716 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -346,7 +346,9 @@ The targets are as follows:
> architecture-dependent or not), it must still exist and must always
> succeed.
>
> - The ``binary`` targets must be invoked as root. [#]_
> + The ``binary`` targets may be invoked as root depending on the
> + value of the :ref:`Rules-Requires-Root <s-f-Rules-Requires-Root>`
> + field. [#]_
I have difficulty parsing this sentence. I think I know what is meant.
The ``binary`` may always be invoked as root, but depending on the value
of R³, it may also not.
> ``clean`` (required)
> This must undo any effects that the ``build`` and ``binary``
> @@ -435,6 +437,12 @@ should not be used to get the CPU or system information;
> the
> that. GNU style variables should generally only be used with upstream
> build systems.
>
> +The builder may set ``DEB_RULES_REQUIRES_ROOT`` environment variable
> +when calling any of the mandatory targets as defined in
> +:ref:`Rules-Requires-Root <s-f-Rules-Requires-Root>`. If the variable
> +is not set, the package must behave as if it was set to
> +``binary-targets``.
> +
> .. _s-debianrules-options:
>
> ``debian/rules`` and ``DEB_BUILD_OPTIONS``
> @@ -525,6 +533,53 @@ order to make it work for your package.
> # Code to run the package test suite.
> endif
>
> +
> +.. _s-debianrules-gainrootapi:
> +
> +``debian/rules`` and ``Rules-Requires-Root``
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Depending on the value of the :ref:`Rules-Requires-Root
> +<s-f-Rules-Requires-Root>` field, the package builder
> +(e.g. dpkg-buildpackage) may run the ``debian/rules`` target as an
> +unprivileged user and provide a `gain root command`. This command
> +allows the ``debian/rules`` target to run particular subcommands under
^^^^^^ lintian will tell you this should be "enables"
> +(fake)root.
> +
> +The `gain root command` is passed to the build script via the
> +``DEB_GAIN_ROOT_CMD`` environment variable. The contents of this
> +variable is a space separated list, the first entry of which is the
> +command, and the proceeding entries of which are arguments to the
> +command. The `gain root command` must be available via PATH. The
> +`gain root command` must not rely on shell features because it need
> +not be used via a shell.
I am not a native speaker, but isn't "doesn't need to" more natural?
Otherwise it should be "needs" I guess.
> +
> +The `gain root command` must not run interactively, including
> +prompting for any user input. It must be possible to prepend the
> +`gain root command` to an existing command and its arguments, without
> +needing to alter or quote the existing command and its arguments.
> +Furthermore, the `gain root command` must preserve all environment
> +variables without the caller having to explicitly request any
> +preservation.
> +
> +The following are examples of valid gain root commands (in syntax of
`gain root command`s ?
> +sh), assuming the tools used are available and properly configured::
> +
> + # Command "sudo", with arguments "-nE" and "--"
> + export DEB_GAIN_ROOT_CMD='sudo -nE --'
> + # Command "fakeroot" with the single argument "--"
> + export DEB_GAIN_ROOT_CMD='fakeroot --'
> +
> +Examples of valid use of the `gain root command`::
> +
> + # sh-syntax (assumes set -e semantics for error handling)
> + $DEB_GAIN_ROOT_CMD some-cmd --which-requires-root
> +
> + # perl
> + my @cmd = ('some-cmd', '--which-requires-root');
> + unshift(@cmd, split(' ', $ENV{DEB_GAIN_ROOT_CMD})) if
> $ENV{DEB_GAIN_ROOT_CMD};
> + system(@cmd) == or die("@cmd failed");
> +
> .. _s-substvars:
>
> Variable substitutions: ``debian/substvars``
> diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
> index ec61f95..ad24eeb 100644
> --- a/policy/upgrading-checklist.rst
> +++ b/policy/upgrading-checklist.rst
> @@ -39,6 +39,18 @@ The sections in this checklist match the values for the
> except in the two anomalous historical cases where normative
> requirements were changed in a minor patch release.
>
> +Version 4.1.5
> +-------------
> +
> +Unreleased.
> +
> +4.9.2
> + Document how ``debian/rules`` and the ``Rules-Requires-Root``
> + field interact.
> +
> +5.6.31
> + Document the ``Rules-Requires-Root`` field.
> +
> Version 4.1.4
> -------------
signature.asc
Description: OpenPGP digital signature
