Replace setuptools bdist_rpm before its deprecation

[deeplow]

bdist_rpm, our current .rpm packaging tool is on its way to the grave. We need to replace it before deprecation. The deprecation reasoning is that the setuptools devs want to focus only on supporting building for pypi.

[deeplow]

CxFreeze (our packaging method MacOS) have merged the code from bdist_rpm into their code base in preparation for this deprecation.

Using CxFreeze for .rpm packaging may turn out to be a viable solution.

[deeplow]

Turns out that bdist_rpm is preventing execution of new Dangerzone installations (see #514). Rather than fix it, we will do our own RPM packaging, which would need to happen anyhow due to the present issue.

[deeplow]

Python RPM packaging findings

RPM packaging python packages has had recent changes, according to the docs:

This version of Python Packaging Guidelines is in effect since 2021 and represents a major rewrite and paradigm shift. Not all packages are updated to reflect this.

In particular rpmbuild can now generate Fedora dependencies from our pyproject.toml file (in theory).

The python3 macros are documented here.

[apyrgio]

pyproject.toml vs setup.py

The modern Python and Fedora packaging guidelines use pyproject.toml as the source of truth for creating Python packages, instead of setup.py:

• https://peps.python.org/pep-0517/#source-trees
• https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html
• https://peps.python.org/pep-0517/
• https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/

Our pyproject.toml currently misses a few things before it can be used to create a Python source distribution (tarball). Namely, it does not include non-Python data files.

Note that this list of data files is already defined in our setup.py script. In that script, one can find some extra goodies:

1. We can conditionally include data files in our Python package. We use this to include Qubes data only in our Qubes packages.
2. We can specify where will the data files be installed in the end-user system.

The above are non-goals for Poetry (see python-poetry/poetry#890) especially point (2), because modern Python wheels are not supposed to install files in arbitrary places within the user's host, nor should the install invocation use sudo. Instead, this is a task that's better suited for the .deb / .rpm packages.

Ultimately, we have to accept this Poetry shortcoming and include package data in our source distributions unconditionally, and without specifying a target installation path.