Hacker News new | ask | show | jobs
by qwerty456127 1903 days ago
> That seems like a ton of effort for them to keep up with, though. Would it not be easier to make an appimage?

I'm curious where does this myth come from. Making a Debian or an Arch package doesn't seem any hard.

2 comments

I am not a Linux guru, so I might have the wrong impression about how much effort is really needed. But I don't think it's just "a Debian or an Arch package". Having a .deb and .rpm gets you most distributions. Arch uses something else. Then Solus uses .eopkg, etc. Probably, you throw up your hands at some point and just make a snap or flatpak package.

Sublime probably has the right of it in maintaining their own repository. Otherwise you're stuck waiting for approvals, or you need to provide instructions for what to do with the package once its downloaded from your site (my printer drivers were like this).

I really only have perspective from the other side: as a user trying to install stuff.

Finding stuff in the package manager is nice. I still have to go to the project's site to check if it's the most recent version, but usually I don't care that much.

Then there are oddities like Calibre, which tells you to ignore your package manager's version and paste some stuff into your terminal with sudo.

Sagemath just tells you to download a binary, which is pretty much the same experience as an appimage. But their files are named sage*Ubuntu|Debian*.tar.bz2, so I'm honestly not really sure what they are or if they work with, say, Arch. I'm pretty sure everyone just installs it through conda anyway.

So I'm always pumped when I see an appimage on a company's site. I know it's coming from the source, I know it's the latest version, and I know all I need to do to run it is to make it executable.

> But I don't think it's just "a Debian or an Arch package". Having a .deb and .rpm gets you most distributions. Arch uses something else. Then Solus uses .eopkg, etc.

Packaging for Debian is pretty much just a tar you throw all your stuff into. Same for arch. Once decided I wanted to package a personal project for arch and was done integrating it into gitlab ci without any prior knowledge.

Your main problem as a company is that your stuff is proprietary and proprietary things dont get accepted into the default repos period.

> So I'm always pumped when I see an appimage on a company's site. I know it's coming from the source, I know it's the latest version, and I know all I need to do to run it is to make it executable.

As a user, I'm always horrified when I see an appimage. It tells me that the developement process of the project is so broken there was no way for them to target my system. It could have openssl from 2007 in there. It may be vulnerable to bugs that where patched decades ago! On top of that, the software wont even update with the rest of my system, leaving me as the maintainer of my software, the whole reason package managers where invented...

Because a Debian package doesn't magically work everywhere. It's not even guaranteed to worl on every Debian system, due to API/ABI breakages in Debian Stable versions and then people also use Debian Testing and Sid. Hence if you want to declare support for Ubuntu 16.04, 18.04, 20.04, Debian 9, Debian 10, ... you either need to rebuild for each of those systems, or monitor ABI/API compatibility with proper testing, or link statically all of the dependencies you use. None of that is as easy as preparing a Debian package.
It's a painful process yes. When you want to use a library that depends on OpenSSL 1.1.1 for instance but you're stuck with 1.0 on CentOS/RHEL 7