[CentOS-devel] Building python38-createrepo_c in CentOS 8 Stream

Wed Mar 2 12:12:04 UTC 2022
Ewoud Kohl van Wijngaarden <ewoud+centos at kohlvanwijngaarden.nl>

On Wed, Mar 02, 2022 at 11:44:10AM +0100, Miro Hrončok wrote:
>On 02. 03. 22 11:16, Ewoud Kohl van Wijngaarden wrote:
>>Hello everyone,
>>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 
>>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 
>>   - cannot install both createrepo_c-libs-0.17.7-3.2.el8.x86_64 and 
>>   - cannot install the best update candidate for package 
>>   - cannot install the best update candidate for package 
>>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.

I had hoped I could get this resolved via upstream channels, but I'll 
see if I can use my Red Hat and some internal channel.

>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.

It is maintained here:


(and in other branches)

And it then released here:


What we've been doing now is pretty similar to what you're suggesting: 
bump if c8s bumps. I suppose increasing the epoch could work, but that's 
really not something I'd like to do.

>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).

It feels like with this you'd still need to keep an eye on upstream to 
see about any updates. It sounds like a lot of work which can introduce 

>Both approaches have advantages and disadvantages.

I think for the short term we'll stick with following Stream and 
bumping if needed while opening the discussion internally.