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 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?
Regards, Ewoud
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.
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,
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.
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:
https://github.com/theforeman/pulpcore-packaging/tree/rpm/3.16/packages/crea...
(and in other branches)
And it then released here:
https://yum.theforeman.org/pulpcore/
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 risk.
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.
On 02. 03. 22 13:12, Ewoud Kohl van Wijngaarden wrote:
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,
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.
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:
https://github.com/theforeman/pulpcore-packaging/tree/rpm/3.16/packages/crea...
Oh, this uses SCL? I don't really understand the SCL-ness of the spec, but something like this should do:
https://github.com/theforeman/pulpcore-packaging/pull/407
-
Ewoud Kohl van Wijngaarden -
Miro Hrončok