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, 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, currently this means binary-targets, and you should read on below. Please note that we want to change this default to no. If your package relies on the current behaviour, building it will break. (We want to change this default, but there is no timeline yet.)
Getting your package ready for Rules-Requires-Root: no
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.