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/createrepo_c (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.