Is it an oversight that flatpak doesn't provide a mechanism to check for updates?

I've been through the documentation for the flatpak command and there doesn't appear to be anything.

Sure there is the update function but that updates all and anything.

How does a technology that claims to be "The future of packaging on Linux" not provide this simple function.

Am I wrong in wanting to update flatpaks selectively after seeing what's available?

@neildarlow flatpaks are a solution to a non-existent problem. Either statically compile everything in (if you’re one of those dirty hippy companies that don’t like to play nice with OSS) or get help packaging it. A lot of maintainers of existing packaging can either give you hints, point you to automated services, or similar.

Packages, are by and large, a solved problem

Follow

@nathand

Packages themselves are. Desktop software isolation isn't at all. When it comes to application isolation MacOS, Android and even Windows is ahead of the common linux desktop. Obviously technically you can employ SELinux rules and what not on applications, but let's look at the adoption of that in the real world.

And that's actually one of the problems Flatpak and Snap are working on to solve. Are the perfect at that? No. But the path is there.

/cc @neildarlow

@sheogorath I won't deny that adoption of SELinux and AppArmor rules is... low under desktop environments. I *would* however posit that it is the *most* appropriate method to provide this kind of security. Flatpak, AppImage and Snap just "throw the baby out with the bathwater".

The technical tools are there, and well developed. These can be better integrated with the distribution, and automatically packaged through the existing channels.

Lets not replace what isn't broken.

@neildarlow

@nathand Sadly classic packages are pretty much broken. Not necessarily always and everywhere, but just have a look at issue trackers and how often people complain or need to fix package conflicts. Fully automated updates? No way.

Guess why most firmware is not package based. Because you can't estimate the state of the system due to dynamic code that is executed in unknown order + user interference. That's why things like OSTree exist. Classic packages are fine, but not good.

/cc @neildarlow

@sheogorath

I don't see how packages are "broken". Yes, things do *break* on occasion. Humans are trying to manage a system, they often do it poorly. Package conflicts can be a part of that, but fully automated updates on Debian stable is pretty much already here.

Firmware is a tricky one. Dell doesn't even automatically push firmware to their own devices through their own software. Apple is the only one I've seen do it, and it does break on occasion. Nothing is perfect.

@neildarlow

@nathand On the low level components, like firmware we still have some problems, yes. But That's pretty much solved by A/B updates (which again, are pretty hard when using linux packages, but not impossible, see rpm-ostree).

But for everything on top? Look at Android, iOS, MacOS, Windows "Apps". All of them are self-contained formats. Install, updates, remove. The app itself, might breaks, but the updates process?

Or how about power losses in the middle of your .deb install?

/cc @neildarlow

@sheogorath Power loss would be an event that is handled, in part, by journaling. A package can then recover that install by unpacking itself over the existing install.

You don't magically fix these unexpected events with app packages. If you loose power during a package decompression or download or any other process might result in a corrupted state.

Most systems adopt this format because none of them support any sort of novel "dependency" system. Everything is static and fat.

@neildarlow

@nathand Again, I have to disagree. First of all, the .deb dependency, in worst case, breaks your entire system so it no longer boots. With image based systems with A/B updates, not really.

When it comes to desktop applications true, you can try to re-run your .deb install and hope for the best, but your system is in an unknown state. flatpak on the other hand, uses atomic transitions to update an app. Means it's always in a known-good-state.

/cc @neildarlow

@nathand @neildarlow

I might want to give a little disclosure here: I did my thesis about the flaws of package-based systems and how to solve them. (The answer is pretty much image-based systems for reproducibility and A/B updates to fail back to a working state). OSTree makes it to employ both of those things in combination with very efficient file-based and delta updates. And given that OSTree is the technology beneath flatpak and, well, rpm-ostree, I'm pretty much in for that.

@sheogorath @neildarlow I don't really doubt that ostree and friends are handy tools for deploying updates and deltas thereof.

The idea that a whole new package management system to *replace* the current systems that are decades old and have lots of battle tested experience and works as-intended with all the integration features and only occasional breakage due to bugs or dependency wires being crossed.

Flatpak has to rebuild all this support. No thanks. Reinventing the wheel.

@nathand Is flatpak the ultimate answer to it? No. But it certainly is a step into a better direction.

The existing packaging systems have advantages when it comes to certain things like internal update management, but doing that on the target systems is only introducing problems that require someone who understands the mess to solve them.

For you and me, probably no problem. But for people who are not interested in IT and just want things to work, it certainly is.

/cc @neildarlow

@nathand By the way, if you are interested in how Debian thinks about their package based system and the possible implications, maybe have a look at their dependency hell page:

wiki.debian.org/DependencyHell

@neildarlow

@sheogorath @nathand @neildarlow In addition, application isolation helps solve:
* Everyone agreeing (instead of having to create separate packages for every distro, I can target one distro and have it work on every distro)
* Unmaintained applications and dependencies (this is one of big sells in the enterprise world where containerization got its start, because you can put unmaintained projects behind a firewall and/or up to date services, and keep running them)

@urusan @sheogorath @neildarlow

> * Everyone agreeing (instead of having to create separate packages for every distro, I can target one distro and have it work on every distro)

Oh good. xkcd/standards.

@nathand @sheogorath @neildarlow I don't see the problem here. We aren't just adding one new standard to a pre-existing pile of standards. Containers are different from traditional packaging approaches, which is why trying to use them to replace traditional packaging causes so many problems. It's not like someone would consider vagrant a viable packaging system after all.

Plus, when making a container it's best to have a traditional package to act as a basis for it.

@sheogorath @nathand @neildarlow Really, a major part of why containers took off so much in the enterprise is that small, low support, undocumented, and unmaintained or poorly maintained projects are the norm inside companies. Containers give you an IT solution to the problem, and companies have decades of experience setting up a good security perimeter around their shitty internal software.

Sign in to participate in the conversation
Sheogorath's Microblog

This is my personal microblog. It's filled with my fun, joy and silliness.