Python 3.14 (and future Python versions) bootstrap issue

[hroncok]

Hello.

Now when Fedora deployed the rpmautospec mock plugin in Koji, we have a bootstrap problem.

I suspect the moment we swap Python 3.13 for Python 3.14 in our Python 3.14 side tag (currently planned for Fedora 43), it will no longer be possible to install rpmautospec into the buildroot (as it requires python(abi) = 3.13 and plenty of other packages that do that as well).

We need to figure out how to solve this by May 2025, assuming this does not affect copr. If this also affects copr, we need to figure this out by Oct 2024.

[gotmax23]

Can the Python rebuild side tag be configured to not use the rpmautospec plugin and instead rely on the fallback value already defined in the buildroot until the dependencies are bootstrapped?

Reducing the dependency footprint is also possible. rpm and libgit2 are obviously essential, but things like click and babel can probably be replaced with stdlib counterparts.

Replacing pygit2 with something pure python such as gitpython and then vendoring the other dependencies using a tool like https://github.com/pradyunsg/vendoring to reduce the dependency footprint to zero is also an option, but really not an ideal one.

[hroncok]

Can the Python rebuild side tag be configured to not use the rpmautospec plugin and instead rely on the fallback value already defined in the buildroot until the dependencies are bootstrapped?

Well, the fallback value is 1%{dist}, isn't it? That might conflict with already used NVRs.

[hroncok]

One possible solution is to be able to switch from the mock plugin to the koji plugin in our side tag. The obvious disadvantage is that it means the Koji plugin needs to be maintained forever.

[sgallagher]

Another option worth considering is replacing the Python implementation (using PyGit2) with a C or other compiled language implementation using libgit2 directly.

[hroncok]

Or using Bash 😀 (only partially kidding, but it might work)

[hroncok]

Anyway, if the Python dependnecy footprint is minimal (flit-core, hatchling, or setuptools buildsystem, no runtime deps beyond pygit2), we can plot the path to rpmautospec and use static relese number when bootstrapping the path.

[carlwgeorge]

One possible solution is to be able to switch from the mock plugin to the koji plugin in our side tag.

Is it possible to have a side tag use the koji plugin while the rest of the koji deployment uses the mock plugin? Based on what I had seen so far I was under the impressions it was all or nothing, and the whole deployment used the same method.

[sgallagher]

One possible solution is to be able to switch from the mock plugin to the koji plugin in our side tag.

Is it possible to have a side tag use the koji plugin while the rest of the koji deployment uses the mock plugin? Based on what I had seen so far I was under the impressions it was all or nothing, and the whole deployment used the same method.

No, it's not possible. If the koji plugin is installed, it's part of every action. I mean, we can tweak it so it is a noop most of the time, but it's been decided that it's a dead path forward since we cannot use it for RHEL builders. It's not going to be seeing any development/maintenance work.

[nphilipp]

We need to figure out how to solve this by May 2025, assuming this does not affect copr.

COPR isn’t affected:

• While packages in COPR are backed by git repositories, these repos don’t have meaningful commit log information, which is why we didn’t pursue integrating rpmautospec with it.
• Unlike koji, COPR will happily build and provide the same EVR of a package multiple times.

Reducing the dependency footprint is also possible. rpm and libgit2 are obviously essential, but things like click and babel can probably be replaced with stdlib counterparts.

Even if it doesn’t solve the issue on its own, I plan to split off the CLI to reduce the impact of dependencies: #175

One possible solution is to be able to switch from the mock plugin to the koji plugin in our side tag. The obvious disadvantage is that it means the Koji plugin needs to be maintained forever.

The koji plugin is only a couple of lines of code really – right now less than 20. It can’t yet opt into being run only on a certain side tag, but that it wouldn’t take much code to implement. It would still be more of a hack, but it could work and it would take comparatively little effort.

Another option worth considering is replacing the Python implementation (using PyGit2) with a C or other compiled language implementation using libgit2 directly.

I’ve thought about it as one option to tackle this – would make the rug that could be pulled out under rpmautospec considerably smaller – but it would also be a serious piece of work, not without risk of introducing new or old bugs when porting.

Or using Bash 😀 (only partially kidding, but it might work)

🤔 Sounds painful to me. 😅

[hroncok]

A friendly reminder that we now only have ~half a year to resolve this.