[frmald]

Originally Posted by eschwartz

Hi. I'm a distro package maintainer. The package I maintain for calibre is never outdated, as I update it every week when the new version comes out. See my signature.

That's wonderful and I appreciate that. For now, I'll stick to Debian-based for wealth of packaging, LTS for lack of surprises.

Also, I am a contributor to calibre. I know a great deal about the installation scripts, because I wrote part of them. They're very clean and package-able, and I obsessively tweak them whenever I can make them even more clean and package-able.

That's wonderful and I appreciate that, but perhaps you might consider packaging all useful resources (like the desktop file?) in the "isolated install", to make repackaging easier.

You don't seem to know ANYTHING about how distros work, so I'll give you a hint: Debian unstable packages the very latest 5.7.2, but Debian's official release of Debian will never upgrade calibre, clean or not, because they are STABLE, and they define that as "does not change, for good or ill", and upgrading to a new version of calibre would constitute change.

I've been running linux since 1994, have tried some 6 distros over the years, have maintained a PPA, have successfully broken and unbroken my system at various levels many times etc. But to the point -- Debian backports only provides calibre 3.48 at this time.

Personally, my distro of choice adventurously chooses to upgrade every day, every time anything updates, under the philosophy that yes, you do need to occasionally adapt, and yes, the programs periodically change on you, but new things are fun to learn.

After the bash -> dash change and systemd, I've stuck to LTS's. Which forces me to sometimes go to extraordinary lengths to get decent versions.

The one you "wrote by hand", with the comment "desktop file as seen in Debian", is the one which calibre's own code creates in src/calibre/linux.py, as invoked by either distro packaging (python setup.py install), or via /opt/calibre/calibre_postinstall.

Because putting a normal desktop file in the install directory, or considering independent packaging efforts was... too ideologically disturbing?

Anyway, who am I kidding, calibre even uses BINARY files, instead of scripts, to set up paths. Hence, ebook-viewer vs bin/ebook-viewer. Wonderfully non-discoverable and opaque. I *suppose* it's just a matter of setting up LD_LIBRARY_PATH, but who knows, there's stuff both in lib/ and libexec/.

Did you think Debian just invented the desktop file out of whole cloth?

No, not after seeing the binary launchers in the root folder, and failing to grep LIBDIR in the source code.

wget URL -O installer.sh
less installer.sh
sh installer.sh

I agree, and perhaps you should put that on the install page if you insist on unsupervised installs. Or just a md5sum or something.

I think your setup is sufficiently unusual that generally applicable needs don't map well to your specialized ones. If you're hacking your initrd and booting into a read-only squashfs root, and your sole interest in appimage is because it can extract overlays of the applications you use that don't have side effects on your squashfs root, then you'll be investing a darned lot of your time in repackaging applications for your use case, and, well, I wish you much luck -- but I still don't think this knowledge is very reusable for others.

MX Linux does all that frugal stuff by itself, but it's after all just a live system, like Debian Live etc. Sort of like copying a Live CD to a partition, except MX has very decent tools for updating the squashfs's and maintaining persistence. Hacking the initrd was required only to get btrfs+zstd compressed persistence overlays (instead of the default ext4)

Anyway, the point was that with a clean isolated install process, one can easily generate an appimage, and that image can serve many needs / whims, including my very specialized ones.

The reCAPTCHAs sound odd, I've never gotten a reCAPTCHA once in all my years of using this forum -- including the old days when I visited every single day for years, and the vast periods of time in which I abandoned the forum, then sporadically returned with gaps of up to a year.

Yeah. Forces me to play whack-a-mole for minutes before I can submit a reply. No time to debug that, but it doesn't seem to happen on other forums (maybe they've given up reCAPTCHA, which is, after all, the evil that it is, spam problems notwithstanding). Maybe the forum software could drop reCAPTCHA from logged who post at normal rates and who have already completed reCAPTHA once. Or thrice. But who am I kidding....