On Mon, 14 Oct 2019 20:18:10 +0200 Gregor Riepl <onit...@gmail.com> wrote:
> > As of now, calibre is not of sufficient quality to be part of a > > Debian release and until it drops all Python2 requirements, it must > > be considered RC buggy. > > Is your quality argument based on the Calibre author's shenanigans? > https://www.reddit.com/r/linux/comments/9wodtq/calibre_wont_migrate_to_python_3_author_says_i_am/ No. It is based just on the removal of Python2 from Debian and avoiding special cases. Right now, any and every package in Debian testing which requires Python2 and has no Python3 alternative in Debian or ready for upload is of poor quality for no other reason than that. All such packages are of such poor quality that the package should be removed from testing - in an orderly manner, leaf packages first. That is in the best interests of all users, despite what may or may not happen to any particular subset(s) of users. The decision flow is easy - if the answer in each case is "no", then move on to the next and if you get to the bottom, the bug should be RC. * Has the package already been removed from testing? * Is a Python3-only version already in Debian? * Is a Python3-only version available upstream? * Does the package have any reverse dependencies? * If you get here, it is already too late, there have already been enough warnings. Upgrade the bug to RC and get the package auto-removed from testing. Step and repeat to get to the next packages in the dependency chain. No special pleading. No whining. No excuses. No buts and no exceptions. No "middle ground". Get the packages which have done the work into Debian testing to get us a clean Python3 package list ready for the next release. Volunteer time is our most precious resource and it cannot be wasted on packages which fail to meet release criteria. Requiring Python2 is RC buggy - simple as that. The only manageable way to implement that is to make all leaf packages RC, step and repeat down the chain until this enormous task is complete. Python2 removal is a huge task and I'm only too aware that I don't have the free time now to do much to actually help it. This is the only way to get the removal done and get to the next Debian release - which after all, is the purpose of the testing suite in Debian. I'm aware of the history of calibre but I really don't care about what happens to calibre per se. I just care that calibre is not a special case that ends up blocking fixes to it's dependencies. For example, if any one of the current Python2 dependencies of calibre is able to drop Python2 support and calibre is the only reverse dependency then nothing about the upload removing Python2 support from the dependency should be prevented just because it's used by calibre as opposed to any other random Python2 leaf package. To do that, calibre should be removed from testing as soon as it is clear that a Python3 version of calibre is not available and BEFORE a Python3 version of any one of it's dependencies gets delayed. None of the arguments about users going to other sources apply. This isn't about removing calibre from unstable - only from testing. That's what raising the severity means - autoremoval, not RM. Even if the package was removed from unstable, it's still in Buster and can be installed from there. If that's not good enough then, sorry - I really don't care. The calibre package - as it exists currently in Debian testing - is not of sufficient quality to remain in Debian testing and should be removed as soon as is practical. As it is a leaf package, that should be now, there is no benefit to Debian in any further delay. Precisely the same applies to tftpy and vland and a range of others which I personally care about much more than I care about calibre. Many of those other packages have already been removed from testing and that was the correct step to take for all the right reasons. None of the above relates specifically to calibre either. Any other package in the same position can be substituted without any change in the correctness of the result. > > And in particular: https://bugs.launchpad.net/calibre/+bug/1714107 > > One thing to consider here is the relatively large user base of > Calibre that doesn't know much or care about the Python 2 > deprecation. They will simply perceive dropping Calibre as a bad move > on Debian's side and rush towards other packages of significantly > lower quality. PPAs, Snap and the like do more harm than keeping > compatibility in some way for the time being. Raising the severity of the bug doesn't change any of this. > While I agree that Debian should not put up with stubborn developers, > I also don't agree that end users should take the fall for Debian > maintainer's decisions. > > Perhaps a middle ground has to be found until a viable Py3 fork of > Calibre is available, or someone steps up and writes Py3 > compatibility patches without dropping Py2 support? This here seems > like a good starting to achieve what Calibre's author wants: > https://github.com/plone/Products.CMFPlone/issues/2184#issuecomment-359445243 > > Though, in the long run, somebody will have to convince Kovid that > writing Py3 code is worthwhile... Or take over maintenance. Again, nothing to do with raising the severity of the bug to RC. Calibre is nothing special - it's a Python2 leaf package like vland and tftpy and any one of far too many others. It should be removed from testing on the basis that a Python3 version is not forthcoming and there are dependencies which will be able to drop their Python2 support (or be removed from Debian entirely) once calibre is no longer considered in the rm-python2 transition due it to not being present in testing. Calibre can stay in unstable - it will go FTBFS, of course, but that isn't a problem either, IMHO. It's calibre's problem - not Debian's problem. There's always the option of users installing the old Python2 stuff from Buster to keep calibre hobbling along. Debian is the higher priority here. Calibre would be a nice to have but it does not deserve to cause delays on anybody else's voluntary effort. No package has that right. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgp4uIyKpHi9l.pgp
Description: OpenPGP digital signature
