@kurisu Dependencies on compiled Python libraries. And Tor. And GnuPG, ideally a specific version so I don't have to worry about the shifting API.

@kurisu Hi, I asked for opinions, but now you're just lecturing.

Thanks for your input, please stop now.

@kurisu Yes, I see that opinionated people who don't know what I'm dealing with or what I've already considered, are still quite eager to preach and tell me my question is wrong.

I hear that people don't like it, but honestly, every tech has haters. Saying you dislike something has almost zero signal, it's just noise.

Tell me WHY, and I'll listen. If you just tell me something sucks, I probably won't.

@HerraBRE @kurisu here's why: both take all of the worst parts and none of the best parts of static linking, all of the worst parts and none of the best parts of package repositories, and combine that with empty promises of security and a ticking timebomb of actual security problems

@sir @kurisu The security problems depend on how good a job I do shipping updates. This is indeed a concern.

The security benefits of sandboxing are very real and I disagree with you on that point.

But thank you for having a real opinion! 😄

@HerraBRE @kurisu that's the problem, you're shipping security updates. You're a random. I trust my distro package maintainers WAY more than I trust random applciation developers.

@sir @kurisu Later in the app's lifecycle, I fully expect the distros to take over.

At this early stage though (the app is honestly a bit shit and will need frequent fixing), I expect being able to ship updates faster than the distro release cycle has a lot of value to my users.

So I'm considering what options I have for doing that.

@HerraBRE @kurisu people who want fast updates should use fast distros

@kurisu @sir This is what I am doing now, for Debian derived distros.

And from a security POV, I feel REALLY bad about it. Once you add my repo to your apt sources, I can update any package on your system. I can do so selectively based on your IP address.

Shipping a Snap or Flatpak does imply bloat and does put the onus on me to rebuild and ship when dependencies have security flaws - but at least I can't replace your /usr/sbin/sshd.

Everything has pros and cons.

@sir @HerraBRE @kurisu my other big problem is my distro already has a great package manager. If I can't get packages from my package manager, I can either build from source (and I think possibly the people who will most care about your product will be capable of this), or use the AUR. It's easy, simple, and efficient. Flatpak et al. Require something like a 200mb download, along with the software. It's massive. It's bloated. It doesn't fit with my philosophy.

@kurisu That does help, those are criteria I would like to consider. Thank you!

And FWIW, I'm already building proper Debian packages.

I'm considering what else to teach the build-bot that is likely to give me the most bang for my buck.

@kurisu Maybe I am! But I'd still like to understand the alternatives out there.

@kurisu @HerraBRE
I've installed from flatpak when something was too new to be in the distribution repository. And it was kind of a lot of trouble, honestly, getting both the app and the runtime installed. And my desktop theme didn't work until I installed it independently in the flatpak runtime.

@kurisu @HerraBRE
Which is not to say that Snap is any better...flatpak is more of a standard. I'm only saying that the flatpak experience is not yet all it's cracked up to be.

@kurisu Dependencies that some platforms may have preinstalled, but others will not. Flatpacks and Snaps let me ship my dependencies without breaking other apps.

A binary tarball will either be insufficient (things missing), or it will start overwriting OS default packages.

So it either breaks, or is hideously impolite... or it includes hacks which basically reinvent Snaps or Flatpak (or AppImage).