Story Time

As a maintainer or user of the Koji build system,

I want that rpmautospec Koji plugins work regardless of the Python version installed,

so that upgrading Python doesn't break the functionality of rpmautospec.

Acceptance Criteria

What needs to be done:

• Additionally to what we have (we will still want rpmautospec to be usable e.g. from fedpkg, by normally importing it), we want an installable package that contains rpmautospec (the tool and Python package) living outside the normal Python structure so it doesn't depend on a specific Python version installed.
• To be a Good Citizen™ and not leave around untracked files upon deinstallation of the package, the script should be run with python -B to avoid writing out .pyc files. This doesn't hurt in the normal case either because we pre-generate these files in the normal Python hierarchy when building the package.
• Instead of using the official rpm Python package, we should use librpm directly and wrap what we need from it with ctypes (which is part of the Python stdlib). Tracked in #127.

Background

@churchyard raised good points on the devel ML thread regarding robustness of the pieces that actually have to run in the build root.

Status quo:

• Currently, the Python package lives in the site lib directory, calling rpmautospec runs rpmautospec.cli.main() via its Python entry point.
• The location of the files and the byte-compiled files tie this to the minor version of the Python interpreter the package was built with. The same holds for the Koji and RPM Python packages...
• We use the koji Python package to query information about existing builds, but we don't use that in the part which we run in the build root.
• We use the rpm Python package to compare EVRs and expand macros in the code run in the build root.