AppImage -- clean packaging

[frmald]

Just wanted to report it's quite easy to create a portable AppImage from an isolated calibre install (once you know what to do, that is), with multi-binary support included. That is, after following these steps, you get a compressed AppImage which can be called as /usr/local/bin/calibre, .../ebook-viewer, .../ebook-meta etc (busybox-style).

All in all, packaging calibre didn't require much hacking, so I'm hopeful this recipe should work for future upgrades.

1. Follow the official isolated install instructions (I'm unpacking to /tmp, use /opt or ~/calibre-bin depending on your circumstances):

wget -nv -O- https://download.calibre-ebook.com/linux-installer.sh | sh /dev/stdin install_dir=/tmp isolated=y

2. Minimal customization

cd /tmp/calibre
ln -s resources/images/apple-touch-icon.png calibre.png

cat >AppRun <<'EOF'
#!/bin/sh
mybin=$(cd "$APPDIR"; mybin=$(basename "$ARGV0"); if test -x "$mybin"; then echo "$mybin"; else echo calibre; fi)
"$APPDIR/$mybin" "$@"
EOF
chmod +x AppRun

# desktop file as seen in Debian; only Icon= and Exec= really matter
cat >calibre.desktop <<'EOF'
[Desktop Entry]
Version=1.0
Type=Application
Name=calibre
GenericName=calibre E-book library management
Exec=calibre %F
Icon=calibre
Categories=Office;
X-GNOME-UsesNotifications=true
MimeType=text/plain;application/x-mobipocket-subscription;application/vnd.openxmlformats-officedocument.wordprocessingml.document;text/html;application/x-cbc;application/ereader;application/oebps-package+xml;image/vnd.djvu;application/x-sony-bbeb;application/vnd.ms-word.document.macroenabled.12;text/rtf;text/x-markdown;application/pdf;application/x-cbz;application/x-cbr;application/x-mobi8-ebook;text/fb2+xml;application/vnd.oasis.opendocument.text;application/epub+zip;application/x-mobipocket-ebook;application/xhtml+xml;
EOF

3. Build the appimage -- could take a while

wget https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage -o /tmp/appimagetool
chmod +x /tmp/appimagetool
/tmp/appimagetool /tmp/calibre/ /usr/local/bin/calibre-x86_64.AppImage

4. Create executables, clean up:

(for f in *; do test -x "$f" && test -f "$f" && sudo ln -sf /usr/local/bin/calibre-x86_64.AppImage /usr/local/bin/"$f"; done)
cd
rm -rf /tmp/calibre-installer-cache/ /tmp/calibre /usr/local/bin/AppRun

On my system I get a portable 144M AppImage, while the full install directory is some 348M.

Upgrading is as simple as following the same instructions exactly. To view current version, use `calibre --version`. In case something goes wrong, use `calibre --appimage-extract` and retry.

[kovidgoyal]

Why create an appimage at all??

[frmald]

Originally Posted by kovidgoyal

Why create an appimage at all??

If you mean one could create a /opt/calibre.squashfs, and have it auto mounted from fstab, then yes -- but it's easier to use an executable appimage on ANY linux install. Like when you're not on your own computer...

If you mean "why save space at all", then -- with SSDs, space is a reasonable concern once again. Also, live USB sticks.

Actually I don't see the point of filling up storage with uncompressed binaries and data files in general. One could convert to live ("frugal") installs completely, but even in this case, keeping big applications separate simplifies updating, and also minimizes the live FS image.

[eschwartz]

If you need to save space that badly, use a filesystem that supports native compression. Or use a distro package, mine is 86 mb and not even optimized for size (it has 3 copies of every python file, including two versions of optimized bytecode).

If your goal is simply to enable people that want a portable one-click redistributable because appimage, then that's great and I wish you the best of luck... But the correct medium for that is "wherever people go looking for curated collections of appimages".

Publishing a do-it-yourself guide here accomplishes nothing, since the only people who would be helped by it are the people who don't want to build an installer executable themselves, by hand. They want the output executable.

Kovid has repeatedly rejected recommendations to change the current official distribution format provided by https://calibre-ebook.com on the grounds that tarballs are usable via the current simple instructions, on any Linux distro, without engaging in wrapper fads. None of these wrapper fads add any value that calibre is interested in, and most of them reduce value by requiring complex supporting infrastructure to be installed first (flatpak, snap) and inherently try but fail to sandbox the program and accomplish nothing other than preventing resources such as shell completion, easy access to command line tools, desktop files for *all* the gui programs, proper use of the icon themes, and more, from being installed as intended and usable for the entire system.

It's beautiful that third-party distributors want to make calibre available for their specific use cases. But that's not really Kovid's job, so you're best off publishing this yourself on flathub, the snap store, or in your case, I guess wherever people publish appimages.

[frmald]

I'll try to stay as on-topic as possible. I've searched for appimage recipes, I've found few results, but some other people having problems. It's in the interest of everyone "on the internet" (including me, searching at a later time) to document a solution somewhere in visible search results.

I'm not requesting any changes to the setup process, as I know all too well what a friendly / open-minded response I would run into. As I said in my initial post, I'm just here to report / document something that I spent time on, and which is not easy to figure out based on current search results.

Originally Posted by eschwartz

If your goal is simply to enable people that want a portable one-click redistributable because appimage, then that's great and I wish you the best of luck... But the correct medium for that is "wherever people go looking for curated collections of appimages".

There is no central place for publishing safe AppImage recipes, AFAICT, and documenting a clean, simple packaging was my main goal. Personally, I'm not keen on running random binaries downloaded from the internet. It's possible to have github build appimages automatically from an open source repo (e.g. there's a guy doing that for Firefox ESR) but I'll look at that at some other time.

Publishing a do-it-yourself guide here accomplishes nothing, since the only people who would be helped by it are the people who don't want to build an installer executable themselves, by hand. They want the output executable.

If your goal was to dissuade me from posting, rest assured that I remembered and anticipated quite well the kind of response I might expect on this forum... But, for documentation purposes, I think this was the right forum to post my report.

Kovid has repeatedly rejected recommendations to change the current official distribution format

Thankfully, the isolated install is good at touching nothing else but the target directory. OTOH, people don't want bare tarballs, so on top of FOSS software, there are various packaging / integration efforts. As you know, distro packages are hopefully outdated (perhaps because there is no "clean", package-able installation script, but who am I to judge).

accomplish nothing other than preventing resources such as shell completion, easy access to command line tools, desktop files for *all* the gui programs, proper use of the icon themes, and more, from being installed as intended and usable for the entire system.

First of all, WHAT desktop files? I had to write one by hand.

Most people don't want unsupervised installs (e.g. wget+sh), since you don't know what it does to your system, it provides no security in transferring the packages (wget+sh + MITM/hacked website etc) and it may pollute the filesystem with artifacts if the uninstallation fails (or is buggy).

If you need to save space that badly, use a filesystem that supports native compression. Or use a distro package, mine is 86 mb and not even optimized for size (it has 3 copies of every python file, including two versions of optimized bytecode).

MX Linux frugal-install here, with a zstd-compressed base (live) squashfs and btrfs+zstd overlays for home and root persistence. Had to hack the MX/antiX initrd for all this... But -- no need for Linux partitions, and the frugal directory, plus AppImage files, can simply be copied to other machines. I try to keep as many big apps out of the base squashfs, for upgradability and to be able to stay under the FAT32 4G limit.

Anyway, thank you for your thoughtful input. It's getting annoying to deal with endless reCAPTCHAs on top of reCAPTCHAs for the same IP on this forum, so I doubt I'll be here much longer.

[kovidgoyal]

What a load of nonsense. The calibre installation includes desktop files. Do a proper installation instead of an isolated one and you will find them.

And distro packages are outdated only in outdated distros, and have to do with the distros' outdated packaging policies, not calibre's installation scripts.

And wget, with https + sh from upstream is FAR MORE secure than downloading some random dude on the internets repackaging of those binaries in random "application format" of the week. This wget + sh bad meme always makes me laugh.

[eschwartz]

Originally Posted by frmald

Thankfully, the isolated install is good at touching nothing else but the target directory. OTOH, people don't want bare tarballs, so on top of FOSS software, there are various packaging / integration efforts. As you know, distro packages are hopefully outdated (perhaps because there is no "clean", package-able installation script, but who am I to judge).

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.

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.

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'm told most people like this "stable" thing. If they're not using Debian stable, they're using CentOS, RHEL, Ubuntu, or Windows 7 (still), because they don't like the entire world changing every other week. Heck -- the official calibre guidance on updating says:

Originally Posted by the fine manual

There is no need to update every week. If you are happy with how calibre works turn off the update notification and be on your merry way. Check back to see if you want to update once a year or so. There is a check box to turn off the update notification, on the update notification itself.

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.

Originally Posted by frmald

First of all, WHAT desktop files? I had to write one by hand.

Yeah, well, that's exactly the problem, isn't it?

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.

Obviously, doing the isolated install does not try to write desktop files, shell completions, icon themes, etc. into the non-isolated /usr/share. Per your choice. So now, there are none to inspect.

Oh well. It's not like an appimage can own files in /usr/share/bash-completion/completions, and the appimage spec explicitly refuses to support multiple .desktop file entry points in one appimage.

...

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

Originally Posted by frmald

Most people don't want unsupervised installs (e.g. wget+sh), since you don't know what it does to your system, it provides no security in transferring the packages (wget+sh + MITM/hacked website etc) and it may pollute the filesystem with artifacts if the uninstallation fails (or is buggy).

I agree, and recommend you use:

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

You then know precisely what it does, which sites it retrieves the binaries from, etc. \o/

Per https://calibre-ebook.com/download you may even manually verify the tarball it retrieves using the PGP signature from https://calibre-ebook.com/signatures, and manually untar it, then execute the calibre_postinstall program to set up system integration.

Originally Posted by frmald

MX Linux frugal-install here, with a zstd-compressed base (live) squashfs and btrfs+zstd overlays for home and root persistence. Had to hack the MX/antiX initrd for all this... But -- no need for Linux partitions, and the frugal directory, plus AppImage files, can simply be copied to other machines. I try to keep as many big apps out of the base squashfs, for upgradability and to be able to stay under the FAT32 4G limit.

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.

Originally Posted by frmald

Anyway, thank you for your thoughtful input. It's getting annoying to deal with endless reCAPTCHAs on top of reCAPTCHAs for the same IP on this forum, so I doubt I'll be here much longer.

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.

[frmald]

Well, I guess we're offtopic, and I'm reacquainting myself to the pleasures of dealing with calibre's human interface. Thanks for the reminder.

Originally Posted by kovidgoyal

What a load of nonsense. The calibre installation includes desktop files. Do a proper installation instead of an isolated one and you will find them.

Ah, so an isolated install, which is the only way to get calibre to NOT make unknowable modifications to the filesystem (short of chroot / pbuilder / overlayfs or other expensive jailing options) is not a "proper installation"? Good to know.

I also particularly like this on the calibre install page: "You can uninstall calibre by running sudo calibre-uninstall. Alternately, simply deleting the installation directory will remove 99% of installed files"

Meaning, if my system hangs, or if there's a bug, I have to trust a non-distribution script to pick up its own trash, without any proper recourse to forcibly remove everything it "improved" on my system.

And distro packages are outdated only in outdated distros, and have to do with the distros' outdated packaging policies, not calibre's installation scripts.

The calibre site itself says "Please do not use your distribution provided calibre package, as those are often buggy/outdated. Instead use the Binary install described below". It sounds a bit different, doesn't it?

And yeah, I know I can run Debian testing / Sid / Ubuntu non-LTS (giving up maintainability and control over key system setup), or switch to Arch or Void or worse and give up the wealth of Debian packaging. No thanks.

And wget, with https + sh from upstream is FAR MORE secure than downloading some random dude on the internets repackaging of those binaries in random "application format" of the week. This wget + sh bad meme always makes me laugh.

I think appimage was around before all the other fads. And that's the point of providing a clean appimage recipe -- not having to trust some "random dude".

[kovidgoyal]

Originally Posted by frmald

Well, I guess we're offtopic, and I'm reacquainting myself to the pleasures of dealing with calibre's human interface. Thanks for the reminder.

Ah dealing with linux weenies that labor under the delusion that because they can open a terminal they actually know anything about anything. Thanks for reminding me of the pleasures of dealing with morons on the internet.

Ah, so an isolated install, which is the only way to get calibre to NOT make unknowable modifications to the filesystem (short of chroot / pbuilder / overlayfs or other expensive jailing options) is not a "proper installation"? Good to know.

Obviously, genius, a proper install is a full install, an isolated one is, gasp, isolated, ergo, not proper.

I also particularly like this on the calibre install page: "You can uninstall calibre by running sudo calibre-uninstall. Alternately, simply deleting the installation directory will remove 99% of installed files"

Meaning, if my system hangs, or if there's a bug, I have to trust a non-distribution script to pick up its own trash, without any proper recourse to forcibly remove everything it "improved" on my system.

I suggest you take the trash you call a brain and let yourself out the door. And just in case you dont realize how stupid you sound, if there is a system hang or bug in a distribution install script it will also leave all manner of trash on your system. And unlike with calibre where simply deleting a single dirctory manually cleans out 99% of the files, your much vaunted debian package will leave its trash literally everywhere.

The calibre site itself says "Please do not use your distribution provided calibre package, as those are often buggy/outdated. Instead use the Binary install described below". It sounds a bit different, doesn't it?

Yeah because distro manintainers, with honorable exceptions, like Eli above, exhibit about the same level of competence as you do, which is nil.

And yeah, I know I can run Debian testing / Sid / Ubuntu non-LTS (giving up maintainability and control over key system setup), or switch to Arch or Void or worse and give up the wealth of Debian packaging. No thanks.

Hey why dont you do the world a favor and stop using calibre.

I think appimage was around before all the other fads. And that's the point of providing a clean appimage recipe -- not having to trust some "random dude".

Right, you trust the random dude's software to run on your system and read all your files and data, but you dont trust the same random dude to install software, let me guess, because it has root privileges and could, gasp, destroy all the parts of your system other that dont actually matter, compared to your actual user data. Seriously, grow a brain.

[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....

[eschwartz]

Originally Posted by frmald

Ah, so an isolated install, which is the only way to get calibre to NOT make unknowable modifications to the filesystem (short of chroot / pbuilder / overlayfs or other expensive jailing options) is not a "proper installation"? Good to know.

staging_root=/tmp/calibre-staging-root/usr
# xdg-utils requires various directories to exist rather than creating them, even ones it doesn't even use
mkdir -p "$staging_root"/share/{applications,desktop-directories,icons/hicolor,mime/packages}
XDG_DATA_DIRS="$staging_root"/share XDG_UTILS_INSTALL_MODE=system /opt/calibre/calibre_postinstall --root="$staging_root"

This will run without root privileges and install all "unknowable modifications" to your chosen --root.

Linux distro packagers would know this as analogous to $DESTDIR.

Originally Posted by frmald

I also particularly like this on the calibre install page: "You can uninstall calibre by running sudo calibre-uninstall. Alternately, simply deleting the installation directory will remove 99% of installed files"

Meaning, if my system hangs, or if there's a bug, I have to trust a non-distribution script to pick up its own trash, without any proper recourse to forcibly remove everything it "improved" on my system.

You don't need to like it... it is true. You could read the source code or inspect the resulting script to verify it. Go, open source!

Originally Posted by frmald

The calibre site itself says "Please do not use your distribution provided calibre package, as those are often buggy/outdated. Instead use the Binary install described below". It sounds a bit different, doesn't it?

And yeah, I know I can run Debian testing / Sid / Ubuntu non-LTS (giving up maintainability and control over key system setup), or switch to Arch or Void or worse and give up the wealth of Debian packaging. No thanks.

I don't see the difference you see.

As for switching to Arch "or worse", we have more AUR packages than Debian has packages, period. The supposed wealth of having sheer quantity of package numbers? Firmly on our side. And unlike Debian we don't cheat by splitting every software project into 6+ different subpackages, thereby padding out their package count with stuff that isn't distinctive.
(Debian does this due to policy demanding the default install of a program not include development headers or docs, and further splitting many packges to enable minimal disk usage for unused features.)

But I don't see the problem here. You have an AppImage suitable for your personal use, if not anyone else's.

There were certain... inefficiencies... in your understanding of calibre's current installer, which resulted in you not realizing how easy it is to get things like desktop files, but now you know, and you sort of worked around it already anyway.

Originally Posted by frmald

I think appimage was around before all the other fads. And that's the point of providing a clean appimage recipe -- not having to trust some "random dude".

The first fad is still a fad, though.

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, manually extracted? The AppImage recipe provides nothing in addition to the tarball, other than a manually copied .desktop file, which could be used without AppImage...

This entire thing seems to be some sort of paranoia that the calibre-uninstall script, which is fairly well behaved, is somehow very untrustworthy and leaves "trash" behind.

[frmald]

Originally Posted by kovidgoyal

Ah dealing with linux weenies that labor under the delusion that because they can open a terminal they actually know anything about anything. Thanks for reminding me of the pleasures of dealing with morons on the internet.

Obviously, genius, a proper install is a full install, an isolated one is, gasp, isolated, ergo, not proper.

I suggest you take the trash you call a brain and let yourself out the door. And

Thanks. I've been runnning Linux since 1994, and seen my first ditch day in 1998, if that tells you anything about educational institutions. Please, get a better default mood setting and don't assume so much...

I didn't request any changes to the default install, I didn't even badmouth it before all these nice exchanges. Because I know what to expect. I just posted a packaging report so others, or me at a later time, can find information easily.

[eschwartz]

Originally Posted by frmald

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.

Originally Posted by frmald

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

There's nothing remotely extraordinary about a program that generates desktop files in the Makefile or similar. Which is precisely what `python setup.py install` is.

I don't much care about the binary installer, but as I mentioned above it's not hard to just pass --root to it (and play Freedesktop XDG-utils games for overriding their default target). So I don't see how this is ideologically a battle between ideologies. Given the files are dynamically generated from up to date info, I don't see much point in shipping them again and having postinstall merely copy them. It sounds more complex, essentially busywork.

Originally Posted by frmald

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/.

The from source version uses python scripts.

The binary version is based on https://github.com/kovidgoyal/calibr...nux/launcher.c
I'm not sure why this is especially evil, to use C launchers instead of shellscripts. Why is it supposed to be discoverable? Is a C program that *isn't* a launcher also supposed to be discoverable without disassembling?

[kovidgoyal]

Originally Posted by frmald

Thanks. I've been runnning Linux since 1994, and seen my first ditch day in 1998, if that tells you anything about educational institutions. Please, get a better default mood setting and don't assume so much...

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.

I didn't request any changes to the default install, I didn't even badmouth it before all these nice exchanges. Because I know what to expect. I just posted a packaging report so others, or me at a later time, can find information easily.

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.

[frmald]

As for switching to Arch "or worse", we have more AUR packages than Debian has packages, period. The supposed wealth of having sheer quantity of package numbers? Firmly on our side. And unlike Debian we don't cheat by splitting every software project into 6+ different subpackages, thereby padding out their package count with stuff that isn't distinctive.
(Debian does this due to policy demanding the default install of a program not include development headers or docs, and further splitting many packges to enable minimal disk usage for unused features.)

Sorry, worse as in distros with even fewer packages than Arch / Debian / Void. I kind of like splitting -dev, because of space, but it might not matter that much in a live squashfs. Anyway, I'll try Atrix one of these days, to see if one can reasonably well use runit / s6 and avoid the... other init system.

Thanks for all the info. I'm not sure if the install script is documented officially (I tried backporting to a PPA a long time ago when I still believed in Ubuntu), but if not, this is very useful.