AppImage -- clean packaging

[frmald]

Originally Posted by kovidgoyal

Maybe it's time you educated yourself a little about the OS you have been using for so long. Perhaps use one of those ditch days for a little research at your educational institution.

That was a reference to Caltech. I'm also angered by idiots, but I think your process for identifying idiots is a bit off.

Originally Posted by kovidgoyal

Do I really need to quote all that you said before, ever so politely, telling me about the "pleasures of dealing with calibre's human interface"? Why do people on the internet think they can be just as rude as they like with no consequences. Let me remind you, you are not doing me a favor by choosing to use the software I, and this entire community have created, for free. You will however be doing me a HUGE personal favor by stopping using it.

Good bye and good luck.

In previous incarnations, I have not found a way to not trigger fury. So there.

Otherwise, I do not use calibre as a reader, but I have my own scripts to save metadata in the filename (e.g. DDC). Those scripts hack calibre's libraries. I don't think I can stop using that, as there is no alternative. But I will never accept Calibre's all-or-nothing philosophy and rename/move my files.

[frmald]

Originally Posted by eschwartz

The first fad is still a fad, though.

Everyone has their own pet project of turning back the clock of history...

Originally Posted by eschwartz

If you're not going to trust some random dude, but go to all the effort of setting up an appimage build recipe *and* downloading calibre's binary tarball, why not just stick with the tarball,

Because you get an executable that can be easily run from the external HDD when your girlfriend's computer dies.

[eschwartz]

Originally Posted by frmald

Because you get an executable that can be easily run from the external HDD when your girlfriend's computer dies.

That property is already supplied by the current tarball's relocatable directory tree which is likewise easily stored on an external HDD and run directly... rendering your statement invalid. This is NOT an argument in favor of an AppImage being more useful than sticking with the tarball.

In fact, there's a script in the resources/ directory, calibre-portable.sh, which exists more or less entirely due to the fact that people want to run calibre from USB sticks or external hard drives on linux.

[frmald]

Originally Posted by eschwartz

That property is already supplied by the current tarball's relocatable directory tree which is likewise easily stored on an external HDD and run directly... rendering your statement invalid. This is NOT an argument in favor of an AppImage being more useful than sticking with the tarball.

In fact, there's a script in the resources/ directory, calibre-portable.sh, which exists more or less entirely due to the fact that people want to run calibre from USB sticks or external hard drives on linux.

140M AppImage file vs 350M calibre-portable directory. I think there's usefulness for AppImage, but let's agree to disagree.

[eschwartz]

Originally Posted by frmald

140M AppImage file vs 350M calibre-portable directory. I think there's usefulness for AppImage, but let's agree to disagree.

I didn't say there is "no" usefulness.

I said you're incorrect to state that the usefulness is "you get an executable that can be easily run from the external HDD".

Feel free to continue moving the goalpost, though.

...

I maintain my belief that being concerned about 140M vs. 350M overlaid on a squashfs read-only root instead of filesystems with built-in compression is sufficiently niche that everyone seeing this DIY recipe will consider tarballs easier.

Especially given the advantage of containing the (multiple) desktop files, mimetype icons, shell completions, etc.