Bug#936806: koji: Python2 removal in sid/bullseye

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Bug#936806: koji: Python2 removal in sid/bullseye

Sandro Tosi-6
On Fri, Jan 31, 2020 at 1:06 PM Marek Marczykowski-Górecki
<[hidden email]> wrote:

> On Thu, Jan 30, 2020 at 05:40:55PM -0800, Mike Miller wrote:
> > On Thu, Jan 30, 2020 at 01:36:33 -0500, Sandro Tosi wrote:
> > > yep i came across all of them starting from python-lzma -- do you know
> > > what's the status of the "RedHat infrastructure" in debian? many (if
> > > not all) of those tools are relatively old, not maintained (or just in
> > > life support mode) and most of all, python2 with no port to python3
> > > available
> >
> > Yeah. I was responsible for some of these, but put them up for adoption
> > about a year ago. You've about captured the status, all rpm-related
> > packages in Debian are old, unmaintained, Python 2 only. Updating to
> > Python 3 ports of mock and koji need dnf, yum is abandonware.
> >
> > I've seen a couple threads about packaging dnf (likely not archived),
> > but so far no one has committed enough to file an ITP.
> >
> > There _is_ an ITP for createrepo-c (#912338), a C-only reimplementation,
> > also a koji dependency, but looks like it may have stalled.
> Adding a bunch of people from Fedora, involved in reproducible builds
> before. And also adding Simon, who can help with some of this.
> A little context: Currently Fedora build tools packages in Debian are
> mostly unmaintained. This makes it difficult to have cross-distribution
> cooperation, for example Debian developers with a lot of experience in
> reproducible builds helping with reproducibility of Fedora packages.
> If I understand correctly, it is also one of the things needed to revive
> Fedora reproducibility testing on https://tests.reproducible-builds.org.
> This is about dnf, mock, koji and createrepo-c - and their dependencies
> (if any missing in Debian).
> Simon can do some packaging, but will need help with finding
> maintainers for them, and possibly also packaging some of the
> dependencies - if there are many of them missing.

I sympathize with the willingness to have cross-distributions
collaboration for the reproducibility goal, but looking from a Debian
perspective (and in particular for the python2 removal effort), i cant
help but wonder what is the value of keeping this set of packages
(yum, koji, createrepo, mock, yum-utils; to name only the top-level
ones) in debian _at all_.

should we just remove them (as in RM to ftp.d.o) and let them be
reintroduced, gradually and if interest arises again, at a later time?
This would be my preferred option, given it removes outdated tools
from Debian and allows progress for the py2removal, but i also want to
hear what y'all think

Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Reply | Threaded
Open this post in threaded view

Bug#936806: koji: Python2 removal in sid/bullseye

Mihai Moldovan
* On 1/31/20 8:57 PM, Neal Gompa wrote:

> As for yum and yum-utils, their replacements are dnf and
> dnf-plugins-core (which have subpackages yum and yum-utils
> respectively to act as legacy interfaces).
> My understanding is that Mihai Moldovan was working on this for Debian
> for the past few months. Mihai worked with me upstream in the DNF
> project to get things adapted nicely for Debian packaging in a
> reasonable way. I've added Mihai to the thread to allow him to
> participate.
> Mihai, would you care to chime in on your progress?
Sure, thanks.

I've made a list post introducing the packages at
https://lists.debian.org/debian-devel/2019/09/msg00218.html , but sadly never
received a response.

This is hardly surprising, because the whole RPM stack in Debian is in a sorry
state; essentially abandoned and unmaintained. :(

The crucial "rpm" package has been up for adoption (c.f.,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923352 ) for almost a year and
pretty much all others as well.

I haven't made a formal ITP for my dnf packages because I'm a.) not a Debian
Developer but merely a user and b.) do not *want* to maintain these packages
within Debian. I wouldn't be a good maintainer in the first place since I often
slack on user requests and I just flat out lack the temporal resources to do
this properly.

The dnf packages (and dependencies) I've packaged (and successfully use for
building RPM packages via mock for newer Fedora versions!) are all
Python-3-compatible. I'm not sure if I ever formally removed the
Python-2-variants, but it's likely that I did, since no new packages providing
Python 2 applications were allowed for quite some time.

At least for dnf and mock I don't see any problem with going Python-3-only. yum
sadly is Python-2-only, which could be problematic. Yum is still required to
fetch packages on older distros like CentOS 6 and 7. Then again, dnf provides a
yum-compat-mode, so Debian should just drop the abandoned yum package completely.


signature.asc (916 bytes) Download Attachment