We need specific packages and recent python3.7+ which by default are not bundled in CentOS 7 or CentOS 8. For that I’ve created few months ago three COPR repositories:
in order to help in having working CentOS 7 and 8 templates. Injecting so much packages in our build infrastructure is not feasible in terms of human resources (e.g. see WIP topic https://github.com/QubesOS/qubes-builder/pull/123). Using COPR repositories is acceptable for community templates because all remain in Fedora build infrastructure and it’s Fedora who provides the repositories.
Focusing on the case of CentOS 7, it’s not compatible with latest components based on python3.7+ like
app-pdf-converter and I’m not going to (and I don’t specifically want to) redo what I’ve done for creating a
python38 repository. I can try to fix as I can packages but for Qubes 4.1 I would love to drop it. For example, currently I’ve not built it at all for this release, even not partially.
Why? First, spec file are common to all RPM distro so it means to add several bunch of
if conditions depending on the distro and also depending on the version. Second, CentOS 7 is reaching end of full updates by end of 2020. Only maintenance updates will remain (https://wiki.centos.org/About/Product). So my question is:
how many people is using CentOS 7 and cannot use CentOS 8 for the upcoming Qubes 4.1 release?
Mostly, it’s like the case of Debian version (https://www.debian.org/releases/) with oldstable, oldoldstable etc.
As you may know, I’m in charge of maintaining multiple templates Fedora, CentOS, Gentoo or even a little bit Debian more recently with DNF and reproducible builds tasks so I need to schedule and optimize the time allocated on those tasks in order to accomplish other Qubes topics.