commit 54646b4eb02282ff84d9a85271bddbfff3504125
Merge: b7ee72c c81e77f
Author: Alexandre Detiste <alexandre.detiste@gmail.com>
Date: Sun Aug 25 12:08:14 2024 +0000
Merge branch 'no-fakeroot' into 'master'
Migrate to `debputy` to avoid unnecessary build-depends on `fakeroot`
See merge request games-team/xbill!1
commit c81e77f8ab2e81fbe281ac3a05476d58049d82d7
Author: Niels Thykier <niels@thykier.net>
Date: Sun Jul 21 09:11:59 2024 +0000
Migrate to `debputy` to avoid unnecessary build-depends on `fakeroot`
This MR enables us to produce the `xbill` deb without needing
`fakeroot`.
One custom change for this package is that a patch of upstream's
`Makefile.in` was updated to remove an unnecessary `-o/-g` parameter
to `install`. The patch might be redundant now with a bit more
tweaking (but I did not follow that all the way down).
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 ownership
[#1024544](https://bugs.debian.org/1024544).
Additionally, `fakeroot` has one open unfixed RC bug 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.
* Common editors known to work: emacs (eglot, built-in), vim (with
vim-youcompleteme or vim9lsp), neovim (with nvim-lspconfig).
Longer list of editors that should work (but for which the
editor glue is not known):
https://microsoft.github.io/language-server-protocol/implementors/tools/
The above LSP and lint 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. Note these editor/lint features
requires optional dependencies for `debputy` that are currently not
available in stable(-backports). The features needed for the package
build on the other hand have already been backported to
`stable-backports`.
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 in case that should
be a concern for you.
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 is build around being bit-for-bit
identical with the `dpkg-deb -b`. Once `dpkg-deb` supports the
relevant features, `debputy` will be able to remove its own custom
assembly in favor of `dpkg-deb` without any changes from you.
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 hook targets for these commands 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. Any use of them will
be flagged by any of:
* The LSP feature (when you open/edit the `debian/rules` file)
* The `debputy lint` command
* The `debputy migrate-from-dh` command. This command also works
in stable and can be helpful if your development/host system is
using stable.
Note: The name of the add-on (`zz-debputy-rrr`) is deliberately
crafted such that `debhelper` loads the `debputy` add-on last.
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.
I have not done this in this commit because `lintian` has not been
updated yet to account for this change and would provide conflicting
advice. Keeping the substvars is redundant but avoids the "scary"
warning from lintian.
Alternative solutions
=====================
The use of static ownership is related to a game and a multi-user
score file. An alternative way to avoiding the implicit
build-dependency on `fakeroot` is to remove the multi-user score file
(and therefore the need for the setgid binary). As a side-effect, the
`debputy` migration would also not be necessary.
For me, either approach is step towards removing `fakeroot` as a
critical package. However, removing the multi-user score file is more
involved and have consequences for the feature set of this
pakcage. Therefore, I will not volunteer to do it.
Closing remark
==============
Thanks for considering. In case you have an concern that is not
answered by the above, please let me know.
Among the 4 debian patches available in version 2.1-10 of the package, we noticed the following issues:
![[bug history graph]](https://qa.debian.org/data/bts/graphs/x/xbill.png){kind=link}