Use latest calibre release? Or the packaged Debian version?

[Queso]

Hi! I've just gotten a new Onyx Boox M96C. It's my first e-reader. I got it (mainly) to read PDF books from places like archive.org and academic journal articles in PDF form. Now I need to manage my new collection of downloaded files and I've read good things about calibre.

Right now I'm on Debian Wheezy. Jessie will probably be released in the next few months. Jessie has frozen calibre 2.5. So I'm thinking of "manually" installing calibre 2.5 (using the installation scripts available from the calibre site) on my Wheezy machine for now and, when I upgrade to Jessie, just stick with the packaged version of 2.5. In general, I prefer to let Debian manage my software via aptitude. So this is my current plan.

Question: Or, is there a compelling reason that I should instead track with the release version of calibre and not use the Debian packages? Keep in mind I'm completely new to calibre and haven't used it for anything yet! Thanks for your help.

[chaley]

Some reasons to use the official release instead of a distro release:

• Distro packages often have bugs introduced during packaging.
• Kovid (author of calibre) won't support distro packages.
• You won't have access to bug fixes.
• You won't have access to features added after the distro release.

Take a look at calibre's change log to get an idea of how fast calibre moves and what you will be missing by sticking on 2.5 (current release is 2.20).

On the other hand, if that release works for you and you aren't interested in anything in a later release then have at it.

[Queso]

Thanks for your reply, chaley. Some of your points apply to all Debian-packaged software, so for some things like Firefox and VirtualBox I do track the releases instead of using the default package versions.

Can you comment on ease of upgrading your library from one version to another? If I sit on 2.5 for a year and decide, hey, the latest version has a compelling to feature, will my Calibre Library/ upgrade safely? Is that supported? Or should it be upgraded from a more recent version? Or is that directory/format very stable and there are rarely changes? Thanks!

[DiapDealer]

I'm assuming that any distro-specific package for calibre is probably going to rely on the system included/installed Qt5 libraries. The Qt5 libs distributed with the official calibre installer include modifications to work around some issues and bugs with the official Qt5. I'm guessing that alone might introduce plenty of potential problems with distro-delivered calibre.

[Queso]

Ah, interesting, I wasn't aware of that. Perhaps I will go with calibre release then. Thanks for all the input.

Although, it sure would be nice if the calibre releases could be packaged -- this can be done without any reliance on other packages, I believe.

Oh, ha, I didn't even realize you could install it in your home dir and not as root. That answers that question, that's what I'll do.

But it is a bit scary to just run scripts directly downloaded from github...

[gbm]

Originally Posted by Queso

Ah, interesting, I wasn't aware of that. Perhaps I will go with calibre release then. Thanks for all the input.

Although, it sure would be nice if the calibre releases could be packaged -- this can be done without any reliance on other packages, I believe.

Oh, ha, I didn't even realize you could install it in your home dir and not as root. That answers that question, that's what I'll do.

But it is a bit scary to just run scripts directly downloaded from github...

The binary install uses a signed certificate.

bernie

[jgaiser]

Originally Posted by gbm

The binary install uses a signed certificate.

+1 As far as I know, nobody has been burned with the binary install from Kovid's github.

[eschwartz]

Originally Posted by DiapDealer

I'm assuming that any distro-specific package for calibre is probably going to rely on the system included/installed Qt5 libraries. The Qt5 libs distributed with the official calibre installer include modifications to work around some issues and bugs with the official Qt5. I'm guessing that alone might introduce plenty of potential problems with distro-delivered calibre.

Nope,

Originally Posted by kovidgoyal

That was changed for 2.x and Qt 5

The calibre linux releases are now built on a debian VM with all the bundled dependencies hand compiled by me, using upstream packages (i.e. not debian packages).

As for the OP's problem, almost certainly a library dependency issue (use LD_DEBUG=all to get more information, or just use the calibre binary packages and save yourself lots of headaches).

Qt workarounds are in the calibre source code itself.

Install-from-source is officially sanctioned and is supposed to get you the same results as the binary packages -- absent downstream bugs introduced by packagers.

[chaley]

Originally Posted by eschwartz

Qt workarounds are in the calibre source code itself.

Install-from-source is officially sanctioned and is supposed to get you the same results as the binary packages -- absent downstream bugs introduced by packagers.

All the bug reports from people using Arch that has qt 5.4.1 argue against what you say. Perhaps these people aren't using install-from-source?

[chaley]

Originally Posted by Queso

Can you comment on ease of upgrading your library from one version to another? If I sit on 2.5 for a year and decide, hey, the latest version has a compelling to feature, will my Calibre Library/ upgrade safely? Is that supported? Or should it be upgraded from a more recent version? Or is that directory/format very stable and there are rarely changes? Thanks!

It is trivial to upgrade a Kovid-provided calibre version to another. I am not sure that is the case when switching from a distro package to the Kovid-provided version. Are the paths the same? Does uninstalling the distro package remove the configuration directory? Where *is* the configuration directory when using a distro package? Where is the library when using a distro package? Did the distro package change anything significant? And so on.

[eschwartz]

Originally Posted by Queso

Ah, interesting, I wasn't aware of that. Perhaps I will go with calibre release then. Thanks for all the input.

Although, it sure would be nice if the calibre releases could be packaged -- this can be done without any reliance on other packages, I believe.

Oh, ha, I didn't even realize you could install it in your home dir and not as root. That answers that question, that's what I'll do.

But it is a bit scary to just run scripts directly downloaded from github...

As long as you trust Kovid, I don't see the problem.

Also, GitHubbed code is scrutinized, you can bet if there are problems then packagers and busybodies would see it -- considering how popular calibre is, it is assured.

GitHub has well-secured servers, no need to fear MITM, and the release itself is downloaded with plain old HTTP but verified with a signature downloaded over HTTPS (signed inside the GitHub script).

Also, you want it packaged for automated updating? See: Fully automatic calibre installer/updater for linux

Asking Kovid to provide repo packaging for debian/*buntu/mint ppas, as well as RPMs for fedora/opensuse, and Arch Linux PKGBUILDs, and Gentoo ebuilds, is a little ridiculous -- and unusual, because that is what the repo managers are for. They slack off.

Note -- Arch Linux and Gentoo and some others are rolling-release and bleeding edge so updates happen in a timely manner.
For that matter, there is debian unstable as well.

[DiapDealer]

Originally Posted by eschwartz

Nope,

Qt workarounds are in the calibre source code itself.

I'm sure you're right, but there must be some advantage to distributing a custom-configured/compiled version of Qt5 to platforms to that already have (or can easily get) a version that can work equally well, no?

Don't get me wrong; I'm no Linux purist. I'm perfectly fine with packaging custom system libs like Qt up with software installation programs on Linux platforms, but I'm going to assume it's being done for something other than practice.

[eschwartz]

Originally Posted by chaley

All the bug reports from people using Arch that has qt 5.4.1 argue against what you say. Perhaps these people aren't using install-from-source?

Because Kovid packages Qt 5.4.0...
And he added fixed it.

(How would they install it if not from source -- vs from precompiled binaries?)

[eschwartz]

Originally Posted by chaley

It is trivial to upgrade a Kovid-provided calibre version to another. I am not sure that is the case when switching from a distro package to the Kovid-provided version. Are the paths the same? Does uninstalling the distro package remove the configuration directory? Where *is* the configuration directory when using a distro package? Where is the library when using a distro package? Did the distro package channge anything significant? And so on.

Distro packagers may do some weird patches, but none of them (yet) have rewritten calibre to remove the library switcher and so forth.

All they install is the progam binaries linked to system python, qt, etc.

[eschwartz]

Originally Posted by DiapDealer

I'm sure you're right, but there must be some advantage to distributing a custom-configured/compiled version of Qt5 to platforms to that already have (or can easily get) a version that can work equally well, no?

Don't get me wrong; I'm no Linux purist. I'm perfectly fine with packaging custom system libs like Qt up with software installation programs on Linux platforms, but I'm going to assume it's being done for something other than practice.

Yes, the advantage is that it has all been tested and works whereas packagers can introduce bugs through *well-intentioned* changes. So no matter where your distro is or what they do or how much they tend to laaaaaaaaaaaaaaaag, calibre works and is at the latest version, without clashing with anything else. Most packages IMHO could use a version like that, especially what with most distros freezing the system at a certain point.

Which is basically what this thread is about.

Just pointing out that Kovid hasn't gone on a rampage trying to make it hard for downstream packagers. He lets them make their own problems if they wish.


And FWIW, I use Kovid's binaries, despite using Arch Linux (a bleeding-edge distro) and will continue to do so until the repo maintainers fix a stupid packaging bug and I can trust it will work properly.