State of Calibre in Debian
To counter some recent FUD spread about Calibre in general and Calibre in Debian in particular, here a concise explanation of the current state.
Many might have read my previous post on Calibre as a moratorium, but that was not my intention. Development of Calibre in Debian is continuing, despite the current stall.
Since it seems to be unclear what the current blockers are, there are two orthogonal problems regarding recent Calibre in Debian: One is the update to version 4 and the switch to qtwebengine, one is the purge of Python 2 from Debian.
Current state
Debian sid and testing currently hold Calibre 3.48 based on Python 2. Due to the ongoing purge, necessary modules (in particular python-cherrypy3) have been removed from Debian/sid, making the current Calibre package RC buggy (see this bug report). That means, that within reasonable time frame, Calibre will be removed from testing.
Now for the two orthogonal problems we are facing:
Calibre 4 packaging
Update 20191028: Calibre 4.2 based on Python2 has been uploaded to unstable due to availability of the necessary modules.
Calibre 4 is already packaged for Debian (see the master-4.0 branch in the git repository). Uploading was first blocked due to a disappearing python-pyqt5.qwebengine which was extracted from PyQt5 package into its own. Thanks to the maintainers we now have a Python2 version build from the qtwebengine-opensource-src package.
But that still doesn’t cut it for Calibre 4, because it requires Qt 5.12, but Debian still carries 5.11 (released 1.5 years ago).
So the above mentioned branch is ready for upload as soon as Qt 5.12 is included in Debian.
Python 3
The other big problem is the purge of Python 2 from Debian. Upstream Calibre already supports building Python 3 versions since some months, with ongoing bug fixes. But including this into Debian poses some problems: The first stumbling block was a missing Python3 version of mechanize, which I have adopted after a 7 years hiatus, updated to the newest version and provided Python 3 modules for it.
Packaging for Debian is done in the experimental branch of the git repository, and is again ready to be uploaded to unstable.
But the much bigger concern here is that practically none of the external plugins of Calibre is ready for Python 3. Paired with the fact that probably most users of Calibre are using one or the other external plugin (just to mention Kepub plugin, DeDRM, …), uploading a Python 3 based version of Calibre would break usage for practically all users.
Since I put our (Debian’s) users first, I have thus decided to keep Calibre based on Python 2 as long as Debian allows. Unfortunately the overzealous purge spree has already introduced RC bugs, which means I am now forced to decide whether I upload a version of Calibre that breaks most users, or I don’t upload and see Calibre removed from testing. Not an easy decision.
Thus, my original plan was to keep Calibre based on Python 2 as long as possible, and hope that upstream switches to Python 3 in time before the next Debian release. This would trigger a continuous update of most plugins and would allow users in Debian to have a seamless transition without complete breakage. Unfortunately, this plan seems to be not actually executable.
Now let us return to the FUD spread:
- Calibre is actively developed upstream
- Calibre in Debian is actively maintained
- Calibre is Python 3 ready, but the plugins are not
- Calibre 4 is already in Debian unstable (Python2) and experimental (Python3)
Calibre 4 is ready for Debian as soon as the dependencies are updated - Calibre/Python3 is ready for upload to Debian, but breaks practically all users
Hope that helps everyone to gain some understanding about the current state of Calibre in Debian.
Possibly naive Q from a user: Is it an option to
– rename calibre to calibre-python2
– make a new metapkg calibre that depends on calibre-python2
– upload calibre-python3
– when calibre-python2 is removed from testing, switch calibre dependency to calibre-python3
Advantages:
– python2 version is available in sid
– both versions can be installed alongside for evaluation and bugreporting, before switching completely
A new package name is a significant event, but after all, this is an backward-incompatible change that breaks major functionality.
Hi
I was thinking about shipping both Calibre/Py2 and Calibre/Py3, but it is a **lot** of work for a few months when Py2 will be definitely removed. I am not sure I have that resources available at the moment, though if someone wants to contribute, by all means, go ahead.
Why does Debian stick with Qt 5.11?
Qt 5.12 is a Long Term Support version (LTS) and suits much better the needs of the project.
https://en.wikipedia.org/wiki/Qt_(software)
The transition is already scheduled, but I don’t know why it took so long. I guess it was too late for Buster to make the transition, and so it did hang around I guess, but I am not the maintainer.
As a software developer, _I_ know best what lib’s my application requires and how to package those applications. Linux Application Packaging is broken.
I don’t get what you want to say here? Yes Kovid prefers till now Py2, but he, too, will switch at some point. Put the blame on the strange Pythonistas … the whole Py2/Py3 was a prime example of PITA.
> State of Calibre in Debian
> Calibre is Python 3 ready, but the plugins are not
Thanks for the heads up.
I am on Debian Sid. I have the habit of upgrading my Debian every few weeks. After stumbling on your post, I was a bit worried about a broken DeDRM plugin.
Fortunately, as on Sat Oct 26 23:08:58 IST 2019, nothing is broken. I can checkout ADE files from library, and /successfully/ DeDRM those with Calibre 4.0.0+really3.48.dfsg-1. FWIW, here is the working combo:
1. Calibre 4.0.0+really3.48.dfsg-1
2. DeDRM-6.6.1
3. wine:all 3.0.2-3 (Note: This is from snapshot.debian.org)
4. ADE_2.0_Installer.exe
5. KindleForPC-installer-1.16.44025.exe
> python-cherrypy3 python-pyqt5.qwebengine Python 2
You have mentioned above files as critical to working Calibre + Plugins. Now that I have confirmed that nothing is broken at my end, I would like to pin / hold as ALL CRITICAL packages at the current levels.
Given my workflow above, may I know what /all/ packages I should put on hold?
Thanks in advance.
Hi Emacksnotes
For now, as long as you stay at Debian/sid and do **not** install versions from experimental, you should be fine. I will probably upload a version of 4.2 build with Py3 to unstable soon. I cannot really confirm about ADE/wine etc (I never use them), but DeDRM at least works on my side.
Debian testing has moved to Bullseye, which provides calibre via python3. Unfortunately, DeDRM does not seem to be ported to python3, which breaks management of e-books for many use cases. For example, a Linux user cannot check a book out of their library and read it on a pocketbook device.
There is working going on porting the DeDRM tools to Python3, see here: https://github.com/lalmeras/DeDRM_tools/tree/Python3
Status of the current repository is explained here https://github.com/apprenticeharper/DeDRM_tools/issues/979#issuecomment-633209779
Everyone fixes the tool that one needs, those I usually use are now fixed.