> > 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 <dal...@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 <dal...@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 <evg...@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@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
