[tvb12]

That seems like a ton of effort for them to keep up with, though. Would it not be easier to make an appimage?

I use a smaller Linux distribution. I checked the package manager, and there is no Sublime text package. It is available as a "third party" package, which I think fetches a package from the third party's website, then repackages it in the local format. It would mean that I would need to check the third party repository for updates. Alternatively, I could probably find it in the snap or flatpak stores. Not a big deal at all, but I do get nervous when I can't find something in the package manager and can't find an appimage on the company's website.

In short, I really like appimages. Please make appimages!

[ben-schaaf]

> That seems like a ton of effort for them to keep up with, though. Would it not be easier to make an appimage?

It's really not. At SublimeHQ we simply create a deb, the rest of the packages are generated from that automatically. Obviously there's some high initial cost in setting all that up but changes to this kind of infrastructure are very infrequent.

appimages/snap/flatpak cause huge problems for development tools. You need to be able to run system executables in the system environment for stuff like build systems, git, etc.

[woodruffw]

Of course it’s effort, but that’s what end users are paying for! The best software in the world isn’t much use to me if it requires me to use a separate, non-first-party distribution system on Linux.

[tvb12]

Distribution is important -- I can't financially support the program if I can't install it on my computer.

However, my money can only support a finite amount of effort. Every bit spent on packaging is taken away from improving the actual program, which is what I really hope I'm paying for.

[woodruffw]

> Every bit spent on packaging is taken away from improving the actual program, which is what I really hope I'm paying for.

Sure, so the reasoning goes: you make it as easy as possible for the 95% of users who like your software (but not enough to change their host to install it), and hope that the remaining 5% are die-hards who are willing to do it themselves. That's why Sublime Text supports the five flavors that it does.

Put another way: you can make it so that your engineers spend almost none of their time on packaging, but your average user isn't dedicated enough to wade away from their default packaging ecosystem. Better to spend a very modest (as other commenters have pointed out) amount of effort supporting the common package formats than to throw those users away.

[tvb12]

I probably have a bad impression of how much effort is required to maintain packages for various distributions, then.

My only remaining point is that AppImage is supported by all of the distributions they support, as well as a few they don't.

[chousuke]

Building distribution packages really doesn't take all that much effort if your build system is sane, and once the initial work is done, your CI will let you know when maintenance is needed.

When you're building your own packages, you can reasonably take shortcuts that distros would not allow (like internet access during build, or vendoring some tricky dependencies), so for many things the packaging just amounts to specifying your dependencies, running your build, and perhaps applying some distro-specific tweaks.

[nly]

This is true, but a lot of the Debian tools are open source biased in that they really don't want you putting together binary packages that install things in to /opt, and don't provide a super convenient way to determine binary package dependencies without going through one of the debhelper build scripts

[oneplane]

Most packaging systems are fairly easy to use. It only becomes a problem if you're doing very weird things, like using very old, or very new libraries, or spreading files all over the system.

[everybodyknows]

Can you point us to a comparative review of appimage, snap, and flatpak? Clearly there are many apple-to-orange tradeoffs, leaving package naifs like me a bit baffled.

[zamadatix]

Not sure about the specifics of your distribution as you didn't name it but that sounds like how it works on all distros supported in the link above. E.g. on Ubuntu you're adding a 3rd party repository to your apt sources not just pulling it from the Ubuntu repos out of the box.

[qwerty456127]

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

[tvb12]

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.

[f1refly]

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

[wander_homer]

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.

[nly]

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

[aliceryhl]

It probably is easier with appimage, but I don't think the difference would be that large. Certainly not a ton of effort.