[eschwartz]

Thanks for fixing the downstream manpages.

Note that you should probably be getting the command list the same way calibre's build process gets them. With that in mind, the following shell command prints out a newline-separated list of binaries calibre installs to /usr/bin:

cd /path/to/calibre-sourcecode/
printf "import sys, os; sys.path.insert(0, os.path.abspath('.')); import setup; setup.initialize_constants(); \nfor i in setup.basenames['gui'] + setup.basenames['console']: print(i);" | python2

Originally Posted by norbusan

Hi

thanks for your long email, and I am more than happy to work with you and the Calibre team for better packaging.

But mark one thing: I'm not the official maintainer of Calibre in Debian, but I am trying to contribute!

That's okay. I just don't have time or inclination to figure out what it takes to contribute packaging instructions for Debian, nor figure out the bugtracker.
I already do all that as a contributing *user* in Arch Linux, plus I don't really grok Debian much.

Can you be a bit more specific? The current packages do ship desktop files:

/usr/share/applications/calibre-gui.desktop
/usr/share/applications/ebook-viewer.desktop
/usr/share/applications/lrfviewer.desktop

and I don't see anything being removed after the call to install. If you can point out what is missing from the curretn calibre 3.1.1 packages, I will surely fix that!

Consider the differences in the filelists for the debian package calibre v3.1.1 and the Arch Linux package calibre v3.1.0.

Downloading and extracting calibre_3.1.1+dfsg-1_all.deb:data.tar.xz -- what do I see?

Those aren't the desktop files calibre installs, they have different content from the four desktop files shipped in calibre's codebase (or technically, the install target of calibre's python build system will generate them programmatically from the codebase, making use of e.g. an up-to-date list of gui_scripts and associated supported mimetypes):

/usr/share/applications/calibre-ebook-edit.desktop
/usr/share/applications/calibre-ebook-viewer.desktop
/usr/share/applications/calibre-gui.desktop
/usr/share/applications/calibre-lrfviewer.desktop

Debian doesn't even have a forked desktop file for the E-Book Editor at all, which means it won't show up in application menus, and uses downstream desktop files for the other GUI software.
A good policy would be to always rely on upstream desktop files, to save on duplication of effort (unless upstream supplies not desktop files, in which case oops).

Additionally, /usr/share/pixmaps/calibre.png is sourced from manual/resources/logo.png which is wrong, especially because calibre doesn't ship any pixmaps file at all, and instead ships a set of various icons (both application icons for the three distinct GUI applications, and for various ebook mimetypes) in various sizes, in /usr/share/icons/hicolor

Also missing from the debian package is /usr/share/mime/packages/calibre-mimetypes.xml (since Debian provides their own /usr/share/mime/packages/calibre.xml which contains unique content that calibre does not have, so I have no idea why it exists at all or where it came from).

That is a difficult point. Please put yourself for 1min into the position of a distributor with releases etc etc. Debian/stable (and for that matter *ANY* distribution) will have a certain version shipped in the stable release, with no updates. That is how Linux (and not linux, too) distributions work. You need to understand that an update notifier does not help at all.

Ha, do my Arch Linux biases show? If we don't have the latest release available (at a minimum in the testing/staging repos awaiting smoketests or some large soname rebuild) within days of upstream, we consider that something is wrong. There is *no* "stable" Arch Linux release, we are rolling-release.

And the update notifier in calibre is not AFAIK split out between the plugin update notifier and the calibre release update notifier, but either way there are patches in the Debian sources that seem to be trying to wholly get rid of the plugin indexer/installer/updater as well... I admit I haven't tested those patches but merely depended on my reading of the description/patched code.

I am also in part reacting to the perceived attitude of the downstream Debian person who filed a debian-specific, non-upstreamed security bug about the plugin system and decided the best thing was to silently disable things which to most people here are a large part of why calibre is so useful.
So, mea culpa.

Just to give you an example: I am the upstream devloper of TeX Live (4Gb of TeX, fonts, software) distribution, and I wrote our own update manager. At the sam etime I am packaging TeX Live for Debian. And there the update manager is not included, because *it*does*not*make*sense*. Users cannot update, root *should* not update as it breaks the whole Debian packaging infra.

Distributors and upstream have different requirements and targets. Calibre upstream has to accept this, too. It is better to work together instead of pointing fingers.

Sure, and if I was working on the assumption that only the calibre update notifier itself was being disabled, I wouldn't really care.

See the above. Instead of finger pointing, lets try to be civil and see what can be done. First of all, the update functionality is still here, nobody is blocked from using it (and I use it regularly), only the notifier is gone.

If the notifier is disabled and the buttons to access the Get Plugins feature are patched out of the codebase, I am not sure how you do that short of installing it via the ZIP file.

This is a general requirement in Debian that programs should *not* phone home if possible, unless started by the user. The user might be in an environment where certain things are prohibited, not welcome, and just automatically phoning home is not optimal.

Well, calibre does phone home with a unique installation ID, but I didn't argue against patching that out per se, checking for plugin updates seems a lot more reasonable to me.
I do see what you mean though.

So all in all, I don't see any serious problems here, and we can surely work out any differences. But packaging in many cases means compromising, and that means compromising for both sides.

Well, I am coming from the perspective of an Arch Linux user. One of our core beliefs is that upstream software should be built and distributed "as upstream intended", with minimal patching when necessary to ensure it actually builds, or when the patch exists in an as-yet-unpublished-release, etc...

Anyway, if you read down to hear, thanks for your long attention, and all the best

Norbert

All the best.