On 02. 03. 22 11:16, Ewoud Kohl van Wijngaarden wrote:
Hello everyone,
Hello.
I'm sending this on behalf of the packagers of the Pulp project.
The Pulp project uses createrepo_c and in particular the Python bindings. The appstream repository does contain python3-createrepo_c but Pulp needs Python 3.8 so it uses the 3.8 module. There is no python38-createrepo_c so for now we're building it ourselves. The problem shows up when createrepo_c is bumped in CentOS Stream. From repoclosure:
Depsolve Error occured: Problem: package python38-createrepo_c-0.17.7-3.2.el8.x86_64 requires createrepo_c-libs = 0.17.7-3.2.el8, but none of the providers can be installed - cannot install both createrepo_c-libs-0.17.7-4.el8.x86_64 and createrepo_c-libs-0.17.7-3.2.el8.x86_64 - cannot install both createrepo_c-libs-0.17.7-3.2.el8.x86_64 and createrepo_c-libs-0.17.7-4.el8.x86_64 - cannot install the best update candidate for package python38-createrepo_c-0.17.7-3.2.el8.x86_64 - cannot install the best update candidate for package createrepo_c-libs-0.17.7-3.2.el8.x86_64
It would be ideal if CentOS itself built python38-createrepo_c (and possibly also for other Python modules). Is this something that could be done?
Technically yes, but that depends on RHEL business decisions.
If you want to build your own, I think there are two fundamentally different ways to build python38-createrepo_c in c8s.
The first way, that I would use for example in EPEL 8, is to create a python38-createrepo_c component, build the package in there, but not ship createrepo_c-libs at all, but depend on the official one. If you could share your spec file, I can send you an updated version that will do this and fix the dependency thing. You will however need to keep it more or less synced with the baseline createrepo_c package whenever it is updated in RHEL / c8s.
The other way is to namespace the C library on the filesystem and/or include the C library in the Python package.
E.g. instead of /usr/lib64/libcreaterepo_c.so.0.X.Y have something like /usr/lib64/python3.8/site-packages/createrepo_c/libcreaterepo_c.so.0.X.Y.
That requires some changes to make sure the library is found (possibly rpath) but allows you to diverge from the official createrepo_c package version (both updating to newer or letting an old not-updated version rot there as long as it work).
Both approaches have advantages and disadvantages.