@squeakypancakes @HerraBRE Distro support is one thing, must also consider what applications youโre hoping to use
@squeakypancakes @HerraBRE Thatโs why I said โalsoโ ๐
@HerraBRE I used AppImage for the game I released recently and was pretty happy with it, but only because the game doesn't have any possible security concerns. That's where things get interesting, and where AppImage is a terrible idea. I'm still pretty hesitant to use anything-but-apt for those situations.
@Leela @lottie @pea @KitRedgrave AppImage is an interesting option.
All the neither votes: thanks for nothing guys, you're being smug, not helpful.
@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.
@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.
@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 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).
@HerraBRE I would say snaps, but I'm an Ubuntu member. And I worked on Snapcraft for a while.
The big reason is that even though Flatpak exists in my distros it's not setup with repos by default. So users still can't find your stuff.
@ted That's an interesting point.
I've already got automated Debian packaging sorted, so Ubuntu is kinda already taken care of. Flatpak might give me more bang for the buck.
This is all just idle pondering at this point, I wasn't aware of the repo complication, thanks for pointing that out.
@HerraBRE it sounds like you're thinking about them as packaging formats, which they are, but that's not the most interesting part. The biggest change is converting to a confinement model for your application. It puts a lot of pressure on developers for a huge user win, though developers get wins too in a more direct access to their users.
For instance, you can make a snap from a deb really easily. But it may not work.
Also, I don't expect my next Ubuntu desktop to be able to install debs.
@squeakypancakes @HerraBRE I don't know stats, but I imagine the number of people that have the flatpak handles for websites to be really small.
For instance, that wouldn't work on my machines because I use the upstream Firefox snap and it can't install stuff in my machine (a good thing).
@ted @HerraBRE You can host the flatpak file on your site as they're really small (libreoffice is only 3.9kb) and have it point to flathub or another repo.
Even if you are sand boxed in you still prolly have you Downloads folder exposed if you need to download something. You should just be able to click on them and let Gnome software or Discover install it from there.
@HerraBRE personal opinion: neither. The only new packaging systems worth a damn are Nix/Guix, which have specific mechanisms to address the flaws of part of their model.
@samis I realized I didn't express very clearly WHY I am asking this question... but answers which require all my potential users switch operating systems before using my software are out of scope. ๐คช
@HerraBRE Neither of them are exclusively system package managers, they can easily run on the same system as another, without interfering with it.
@samis That's interesting, I did not know that.
But if I have to ask people to first install a package manager before they can install my software, that's still kinda the same thing, isn't it?
@HerraBRE You could bundle it with the initial download of your software.
@samis We're back when we started then: what is the format of that initial download?
@HerraBRE Given the contents of the download, a self-extracting archive is sufficient for this stage.
@HerraBRE Flatpak. Its supported my more distros https://kamikazow.wordpress.com/2018/06/08/adoption-of-flatpak-vs-snap-2018-edition/
and theres even projects using it to solve real problems such as winepak
https://www.winepak.org/