[Pulp-dev] pulp-owned pypi packages that pulp did not author

Daniel Alley dalley at redhat.com
Tue Jul 14 15:21:39 UTC 2020


>
> Thanks Daniel,
>
> I've reposted to pulp-dev, so you might want to re-post your reply
> there too, but:
>
> Great, if createrepo and libcomps is just "intermediate" while we
> actively (try) to help upstream get there, I can totally take that.
>
> For solv: well, if they don't want it there, IMHO we should not
> publish it under their name either?


It's not so much that they didn't want it there; more that they don't care
about that use case at all and it's not something that they want to
maintain or think about.  Similar to the situation with createrepo_c except
that there was less hope that they would eventually take back control :)

The primary reason is just that we wanted it to be possible to run the RPM
plugin on Debian-based distros, and relying on any RPMs would go counter to
that goal.  But there were some other motivations also - at the time, the
Python community was deciding on which technology to use for the new
dependency resolver in Pip, and libsolv was mentioned as a candidate (but
ultimately decided against for various reasons).  One of the reasons was
that nobody had ever made a Python package for libsolv and they weren't
even sure if it was possible - and I found this discussion at the same time
as I was already wanting to package it anyway for Pulp.

>
>
On Tue, Jul 14, 2020 at 9:47 AM Daniel Alley <dalley at redhat.com> wrote:

> My apologies!  s/Evengi/Evgeni, the letters got swapped in my brain : /
>
> On Tue, Jul 14, 2020 at 9:37 AM Daniel Alley <dalley at redhat.com> wrote:
>
>> Reposting my response from the other thread:
>>
>> Hi Evengi,
>>
>> In the case of createrepo_c and libsolv, the upstream merged all of the
>> build script changes that were necessary to enable producing Python
>> packages, so in that sense the packages we are producing are completely
>> unmodified.  However, the RPM team isn't particularly interested in
>> maintaining Python packages, and so they gave us permission to maintain the
>> packages ourselves.  I've forgotten in what medium that discussion took
>> place so I'm not sure where even to look for a record of it.  Nonetheless I
>> actually have a PR open against both projects which would automate the
>> entire packaging and release process for Python packages with Github
>> Actions, so that they could become the official owners/maintainers without
>> actually needing to do any work (hopefully).
>>
>> https://github.com/rpm-software-management/createrepo_c/pull/207
>> https://github.com/rpm-software-management/libcomps/pull/69
>>
>> However you may notice that those PRs have been sitting for a while :)
>> In any case we'd definitely love to transfer ownership back to them, and
>> I've been trying to facilitate that process a little bit (with the PRs) but
>> I don't really want to push on them too hard to do so.
>>
>> With respect to libsolv it's a little more complicated. As far as I can
>> tell the upstream is just not interested at all and would probably not
>> accept the changes into upstream regardless of whether we made the release
>> process automated.  I asked multiple times if they were interested and got
>> essentially no response.
>>
>> https://github.com/openSUSE/libsolv/issues/228
>>
>> + some discussion on IRC
>>
>> Feb 24 10:14:47 <dalley> hello Igor, do you have any opinion on this?
>>> https://github.com/openSUSE/libsolv/issues/228#issuecomment-589915584
>>> Feb 24 10:18:24 <ignatenkobrain> Well, I don't see any reason to publish
>>> libsolv to pypi :)
>>>
>>
>> On Tue, Jul 14, 2020 at 9:31 AM Evgeni Golov <evgeni at redhat.com> wrote:
>>
>>> Hi pulp-dev,
>>>
>>> While packaging pulp3 (more precisely pulp-rpm), I stumbled over the
>>> fact that the "pulp" pypi user has uploaded "solv", "libcomps" and
>>> "createrepo-c" without being the real author. To make matters worse,
>>> the uploads don't 100% represent the original artifacts released by
>>> the respective upstreams as they don't release python packages but
>>> classic tarballs. In the case of "solv" this lead to an interesting
>>> bug: solv upstream does not build a python egg, but your package did,
>>> and then as the pulp-rpm egg has "solv" as a dependency, it won't load on
>>> a system that uses the "real solv" without the egg. We patched that
>>> out in packaging, but it remains ugly.
>>>
>>> I kinda understand why Pulp did that, this way you can rely on "pip"
>>> to install everything for a working pulp-rpm environment, but I think
>>> we/you shouldn't do that and instead either persuade (and help!) the real
>>> upstreams to publish their stuff to PyPI or bite the bullet and accept
>>> that pip is not able to install everything needed for a working
>>> environment.
>>>
>>> Thanks!
>>> Evgeni
>>>
>>> --
>>> Beste Grüße/Kind regards,
>>>
>>> Evgeni Golov
>>> Senior Software Engineer
>>> ________________________________________________________________________
>>> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
>>> Handelsregister: Amtsgericht München, HRB 153243,
>>> Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas
>>> Savage
>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200714/df6154ad/attachment.htm>


More information about the Pulp-dev mailing list