Migrate to `debputy` to avoid needing fakeroot

Hi @cjwatson

This MR enables us to produce man-db debs without needing fakeroot with one left-over TODO for you as maintainer/upstream to fully work. The missing bit is the install-exec-hook in src/Makefile.am, where the following bit should be skipped:

install-exec-hook:
	if [ "$(man_owner)" ] && [ "$(man_mode)" = 6755 ]; then \
		chown $(man_owner):$(man_owner) \
			$(DESTDIR)$(bindir)/$(TRANS_MAN)$(EXEEXT) \
			$(DESTDIR)$(bindir)/$(TRANS_MANDB)$(EXEEXT); \
	fi

I see multiple ways to do this, but I presumed you as maintainer + upstream had your take on how to do it. If it was me, I would have a separate --enable-X option that disables it. Alternatively, one can "hack it" by passing man_owner= to the make install though it might affect other parts. I left this part out, so the MR will FTBFS until resolved. Feel free to ask me to update it with how you want it fixed. Though I am no good in m4 so if you want a new configure option, it might be easier for you to add that first, ask me to rebase and then use that new option.

With the man-db specific part of the MR cleared, here is some more generic parts about the MR.

Avoiding fakeroot

As useful as fakeroot has been, it is also quite fragile. As an example, a slightly out of date fakeroot can cause debs to be contaminated with non-root ownerships #1024544. Additionally, fakeroot has two open unfixed RC bugs filed against it that has made it unable to migrate to testing for a while.

On using debputy

To remove fakeroot, this MR introduces a build dependency on debputy and a new packaging file for specifying the ownership information. The debputy tool is relatively new in Debian and therefore it is likely that you have not used it or seen it in use. To help you getting started, here are some tips that I hope will be useful:

1. debputy comes with its own self-checking features. You can use debputy lint and debputy check-manifest to perform static validation of the packaging.
2. If you use an editor with Language Server support (often referred to as LSP), debputy comes with a Language Server implementation to provide in editor support for the debian/debputy.manifest file (and several other Debian packaging files).
   • Use debputy lsp features to get extra dependencies sorted out followed by debputy lsp editor-config to see which editors have known editor glue.
   • Editors known to work: emacs (eglot, built-in), vim (with vim-youcompleteme or vim9lsp), neovim (with nvim-lspconfig).

The above features may also useful for packages that does not use debputy since the language server and the linting feature applies to generic packaging as well.

The debputy is already part of the critical path for architecture bootstrapping (used by util-linux and shadow). Accordingly, I already have focus on keeping debputy's dependencies easy to handle for architecture bootstrapping and cross-building.

To assemble the deb without fakeroot, debputy has its own deb assembly and will skip dpkg-deb -b for any deb with static ownerships. This internal assembly was build around being bit-for-bit identical with the dpkg-deb -b.

How debputy affects the debhelper sequence

In general, debputy (via dh-debputy) is inserted into the debhelper sequence at the end and replaces a number of debhelper commands. In the current integration mode, the commands being replaced are:

• dh_fixperms
• dh_shlibdeps
• dh_gencontrol
• dh_md5sums
• dh_builddeb

Any override for these will not be respected and any custom features needed from those will have to be supported and done via debputy. In this MR, I have migrated the necessities and you will find them in debian/debputy.manifest.

You do not have to remember the above commands. You can also use debputy migrate-from-dh to detect any problem hook targets. It is an open TODO to have debputy lint and the language server support flag them as well (debputy#103 (closed)).

Optional improvements

Per https://lists.debian.org/debian-devel/2024/03/msg00303.html, you can also remove ${misc:Depends} and ${shlibs:Depends} as these are applied automatically with debputy. The debputy migrate-from-dh command will flag them if you want to clean up.

Closing remark

Thanks for considering. In case you have an concern that is not answered by the above, please let me know.