Background: during build of a package, dpkg-buildpackage uses a "gain root" tool. This is typically fakeroot. If a package specified Rules-Requires-Root: no or build depends on dpkg-build-api (= 1) in debian/control or has no Rules-Requires-Root field and is built with dpkg-buildpackage >= 1.22.13, no such "gain root" tool is invoked. fakeroot has served the Debian project well, but it is a clever hack that is overstretched now and is not maintainable going forward.
The field Rules-Requires-Root is also sometimes known as R³ or RRR.
Checking your package
If your package already specifies Rules-Requires-Root: no or build depends on dpkg-build-api (= 1) in debian/control, you are done!
If your package specifies Rules-Requires-Root: binary-targets, please read below.
If your package specifies nothing about Rules-Requires-Root, starting with dpkg-buildpackage >= 1.22.13 (Debian trixie) this means no (where previously it meant binary-targets). If your package is part of Debian then it either has a bug report filed with any pending problem, or it works and you are done. If it is a third party package, it might break with the current behavior, and you should read on below.
Getting your package ready for Rules-Requires-Root: no (or no field at all)
The first step is to evaluate if you can just set Rules-Requires-Root: no. Add this line to debian/control and run the build. If the build works, and the result is unchanged (you can check with diffoscope and other tools), please commit this change and upload. You are done.
If Rules-Requires-Root: no does not work:
When ownership/permissions are necessary in the installed system
Some packages want to install a program or another file with special ownership and/or permissions. Usually this is some form of setuid or setgid permission (+x).
If your package is in this category, the best suggestion is to use dh-sequence-zz-debputy-rrr for managing the ownership/permissions. Your package will be in good company; man-db, util-linux, and others use this successfully.
To start using debputy for building without fakeroot, it will take the following steps:
Ensure your package is using the dh sequencer first.
Add Rules-Requires-Root: no to the Source stanza in debian/control or a relevant build depends on dpkg-build-api such as dpkg-build-api (= 1).
Add dh-sequence-zz-debputy-rrr (>= 0.1.43~) to Build-Depends.
Run debputy migrate-from-dh --migration-target dh-sequence-zz-debputy-rrr (Add --no-act if you are not using a VCS and want to examine the changes first). This will provide you with a list of incompatibilities to resolve.
- Feel free to skip the substvars being obsolete warning, since lintian has not been updated yet and will give false-positives (see 1067653)
- For the dh_fixperms hook target(s), then this should be replaced by debian/debputy.manifest. There is a ?real world example of the debputy.manifest from src:shadow. The debputy package also provides a guide for this step: https://salsa.debian.org/debian/debputy/-/blob/main/GETTING-STARTED-WITH-dh-debputy.md?ref_type=heads#convert-your-overrides-or-excludes-for-dh_fixperms-if-any
- You may also want to review https://salsa.debian.org/debian/debputy/-/blob/main/GETTING-STARTED-WITH-dh-debputy.md to supplement the migration output.
- Run the build and compare the results, if ownership/permissions are preserved as you expect.
It should work for most dh-using package. It will remove some debhelper commands (beyond dh_fixperms) from the dh sequence. Please contact the debputy maintainers if you have trouble migration your package.
Upstream Makefile calls install -o root
Some old upstream Makefiles run install -o root -g root or install -o 0 -g 0 or similar. No actual "special" ownership/permissions are implied.
In this case, please patch out the -o root -g root or -o 0 -g 0 (or similar) from the Makefile and set Rules-Requires-Root: no. In some cases, the -o/-g is passed via a Makefile variable where you can override the variable via debian/rules instead of patching. You are done.
When to use Rules-Requires-Root: no (or no field)
If your package has a build dependency on at least dpkg-build-api (= 1), then there is no need for the Rules-Requires-Root field.
If your package needs to build with dpkg-buildpackage both older and newer than 1.22.13, then you should add an explicit Rules-Requires-Root: no, or a build dependency on dpkg-build-api (= 1) if the dpkg version to be used can support it.
If your package can assume that it will be built with dpkg-buildpackage >= 1.22.13 or with Debian trixie or later (or a derivative based on it), then you can omit the Rules-Requires-Root field entirely.