po: Update German man pages translation
[dpkg.git] / doc / spec / rootless-builds.txt
blob5a5af83fa8b03728c4e2ed2ed82ac79873c2cb66
1 Supporting rootless builds
2 ==========================
4 Status: recommendation, stable
5 Version: 1.0
7 Background
8 ----------
10 Traditionally, Debian packages have required (fake)root privileges for some
11 of the "debian/rules" targets. This has required also a split between build
12 and binary targets; making the builds slower, due to the increased amount
13 of invocations of "debian/rules" and the overhead of using fakeroot(1) or
14 equivalent fake environments, or less secure due to the increased dangers
15 of running under real root via sudo or equivalent.
17 On this document when talking about "(fake)root" privileges, it will refer
18 to any mechanism, supported by the dpkg-buildpackage "-r/--root-command"
19 option, that can provide either a real or faked root user environment.
21 Specification
22 -------------
24 We add a new field to the "Source" stanza of debian/control:
26   Rules-Requires-Root: no | binary-targets | <implementations-keywords>
28 The case sensitive values are defined as:
30  * If "no", then "debian/rules binary" will not require root at all (not even
31    fakeroot). This is the default in dpkg-build-api level >= 1.
32    - If the "no" keyword is used, it MUST be the only keyword in that field
33      and MUST appear exactly once.
35  * If "binary-targets", then "debian/rules binary" (etc.) must always be run
36    under (fake)root. This is the status quo, default in dpkg-build-api level 0.
38  * <implementations-keywords> will be a space separated list of keywords which
39    define when root is required.
41    - Keywords consists of <namespace>/<cases>. The "namespace" part cannot
42      contain "/" or whitespace. The "cases" part cannot contain whitespace.
43      Furthermore, both parts MUST consist entirely of printable ASCII
44      characters.
46    - Each tool/package will define a namespace named after itself and provide
47      a number of cases where (fake)root is required.
48      (See also "Implementation provided keywords".)
50    - When "Rules-Requires-Root" is set to <implementations-keywords>, the
51      builder (i.e. whatever is executing debian/rules) will expose an
52      interface that is used to run a command under (fake)root via the
53      "Gain Root API". If the builder cannot provide such a command, it
54      MUST behave like "Rules-Requires-Root" was set to "binary-targets",
55      i.e. run "debian/rules binary" under (fake)root.
57 When the builder supports this specification, it MUST notify this fact to
58 the rules file via the "DEB_RULES_REQUIRES_ROOT" environment variable, with
59 the value it has obtained from the Rules-Requires-Root field or some builder
60 specific override mechanism, which will denote the level of support the
61 builder has chosen to commit to take effect during the build. When set,
62 it MUST be a valid value for the Rules-Requires-Root field. If unset,
63 the build system SHOULD assume that the builder does not recognize the
64 Rules-Requires-Root field at all.
66 It is always permissible for a builder to ignore this field and fall back to
67 running the binary targets under (fake)root. This is to ensure backwards
68 compatibility when builds are performed by legacy builders or older versions
69 of the tooling.
71 Tools called from the rules file MUST cope gracefully with being called under
72 (fake)root even when Rules-Requires-Root is set to a value that implies they
73 should not be (e.g. "no"). However, they MUST NOT attempt to run processes
74 under (fake)root when run as a regular user when Rules-Requires-Root does
75 not list any keywords they respond to.
77 Tools MUST gracefully ignore valid unknown keywords outside their namespace.
78 They MAY warn about unknown keywords inside their namespace.
80 The value of this field MUST NOT change the content of the package in any
81 way. Notably, packages that are bit-for-bit reproducible MUST still provide
82 bit-for-bit identical results even when the field is ignored.
84 Implementation provided keywords
85 --------------------------------
87 Keywords provided by various implementations:
89  * dpkg/target-subcommand: When the package needs to run a given command
90    under (fake)root within the "debian/rules" files directly, this MUST be
91    declared via this keyword.
93  * dpkg/target/<target-name>: When a specific "debian/rules" unofficial
94    target (none of the root-requiring "binary-indep", "binary-arch", "binary",
95    "clean", nor the non-root-requiring "build-indep", "build-arch", "build")
96    needs to be run under (fake)root, this MUST be declared via this dynamic
97    keyword, where <target-name> is the name of the "debian/rules" target.
99  * debhelper/upstream-make-install: The dh_auto_install command will run
100    the "install" target from the upstream's Makefile under (fake)root (for
101    the "makefile" build system or one derived from it).
103 Gain Root API
104 -------------
106 The builder will provide a command to promote a given command to (fake)root
107 by exposing it in the environment variable "DEB_GAIN_ROOT_CMD". Tools that
108 need this promotion will then use it like the following:
110     $DEB_GAIN_ROOT_CMD cmd-that-needs-root ...
112 This command is subject to the same requirements as the "gain-root-command"
113 that dpkg-buildpackage accepts via its "-r/--root-command" option, which
114 means that it can contain space-separated parameters. If dpkg-buildpackage is
115 called with "-r/--root-command", then dpkg-buildpackage shall use that value
116 as the value for "DEB_GAIN_ROOT_CMD". The command SHOULD preserve all the
117 environment variables, unmodified.
119 The variable SHOULD only be provided when there is a need for it. Notably
120 when "Rules-Requires-Root" is either "no" or "binary-targets" the variable
121 SHOULD NOT be defined.
123 (The "DEB_GAIN_ROOT_CMD" variable used to be named "DPKG_GAIN_ROOT_CMD"
124 starting with dpkg 1.19.0 and before dpkg 1.19.1 when this specification
125 got released as stable. The old name MUST not be used.)
127 Common cases
128 ------------
130  * Upstream installation insists on "sudo make install"-like behavior.
131    => Use dpkg/target-subcommand or debhelper/upstream-make-install.
133  * Files shipped in the package must be owned by another user than root.
134    => Not covered; use "binary-targets" for now until dpkg+debhelper
135       provides the required interface.
137 Prototyping/preparation
138 =======================
140 dpkg side
141 ---------
143 dpkg-deb --build provides the --root-owner-group option so that dh_builddeb
144 or direct calls can control the owner/group file values w/o requiring
145 (fake)root.
147 dpkg-buildpackage must export DEB_GAIN_ROOT_CMD when necessary (for
148 prototyping, doing this unconditionally would be fine).
151 debhelper side
152 --------------
154 When the field is present:
156  * dh_testroot will behave as usual when Rules-Requires-Root is not present
157    or set to "binary-targets".
159  * dh_testroot will be a no-op when Rules-Requires-Root is set to "no".
161  * Otherwise, dh_testroot will either verify that it is run under (fake)root
162    (as usual) OR assert that DEB_GAIN_ROOT_CMD is defined.
164  * debhelper build systems will be patched to check for the
165    "debhelper/upstream-make-install" keyword and use the "Gain Root API"
166    accordingly.
168  * All other (src:)debhelper commands will skip their calls to chown
169    (currently they just reset them to "0:0" anyway).
171 With the above, a default "dh $@" will no longer require (fake)root when
172 built (and Rules-Requires-Root is "no").
174 Prototyping:
176  * During prototyping, dh_builddeb can wrap the dpkg-deb --build call with
177    fakeroot (when not already root).