The State of Flatpak In GNOME Software

[phoronix]

Phoronix: The State of Flatpak In GNOME Software

There's a new blog post concerning the state of Flatpak (formerly XDG-App) integration in the GNOME Software app/software store/center...

http://www.phoronix.com/scan.php?page=news_item&px=GNOME-Software-Flatpak

[dh04000]

The funny part is that Gnome-Software is such a nice upstream that Snap are supported as well. Not that anyone should care about awful CLA software like snap but it pretty much sums up the difference between good upstreams and bad upstreams.

Wasn't that functionality that Canonical added? Are you saying that upstream accepted the patches without pulling a "no single distro patch" rejection? Did hell just freeze over?

[RahulSundaram]

Wasn't that functionality that Canonical added? Are you saying that upstream accepted the patches without pulling a "no single distro patch" rejection? Did hell just freeze over?

Individual maintainers on other projects do reject distro specific patches but it is not uncommon for many projects to accept them if they are maintainable. GNOME Software (Snap), GTK, SDL (Mir support) are just a few examples

[edoantonioco]

I'm still not convinced than using runtimes is the best way to proceed. Time will tell which approach is the best one

[computerquip]

I'm still not convinced than using runtimes is the best way to proceed. Time will tell which approach is the best one

As opposed to what?

[Duve]

Individual maintainers on other projects do reject distro specific patches but it is not uncommon for many projects to accept them if they are maintainable. GNOME Software (Snap), GTK, SDL (Mir support) are just a few examples

I expect that, the last thing that anyone project wants is to be holding the bag on distro specific code that they need to preform maintenance on. If those distro's can upkeep the burden, I don't see the point for refusal.

[justmy2cents]

Individual maintainers on other projects do reject distro specific patches but it is not uncommon for many projects to accept them if they are maintainable. GNOME Software (Snap), GTK, SDL (Mir support) are just a few examples

afaik, GS contains all that functionality in plugins which is much easier to maintain than accepting something as part of your code which you need to maintain. if plugin is unmaintained you just drop it from build and it is over

[RahulSundaram]

I expect that, the last thing that anyone project wants is to be holding the bag on distro specific code that they need to preform maintenance on. If those distro's can upkeep the burden, I don't see the point for refusal.

The problem is, that reviewing code etc takes time. If distro that pushes the code doesn't followup after that, you are responsible as maintainer for your users. This isn't a straight forward choice.

afaik, GS contains all that functionality in plugins which is much easier to maintain than accepting something as part of your code which you need to maintain. if plugin is unmaintained you just drop it from build and it is over

Yes.

GNOME Software was explicitly designed by Richard Hughes/ Red Hat to deliver more than RPM content as payload since it was an higher level abstraction layer. Flatpak or other formats can fit into this model easily.

[bkor]

Wasn't that functionality that Canonical added? Are you saying that upstream accepted the patches without pulling a "no single distro patch" rejection? Did hell just freeze over?

"No single distro patch" is NOT a GNOME policy. What is important if it is a code drop, or will it be maintained. That together with how invasive it is to the rest of the project. In a few cases Canonical maintains their code upstream and it is fairly contained. There's no need to reject such things. If Canonical stops maintaining it and it becomes a problem, then the code can be dropped (no "free maintenance").

At times Canonical did try code drops coupled with normal contributions. The code drops haven't happened for _many_ years (AFAIK).

[VanCoding]

As opposed to what?

As opposed to each application having its own runtime in snappy, I think.

And yes, I'm not convinced as well. In the worst case, this takes even more space than without runtimes, because the targeted runtime might include things that your application does not use & this specific runtime is only used by your application.

Plus, with runtimes, your application can break as soon as the runtime updates a lib your app is not compatible with. So we're basically facing the same problem we do right now.

The only thing that bugs me a bit with snappy is, that you have to have to build & include every dependency on your own, and include it into your package. It would be way cooler if library developers could also publish their libraries as snaps & the snap database would store all versions of a libraries ever published. That way, application developers could depend on any specific library version, and then snappy could download it as well when installing your application.

That way, if two applications use the same version of a library, it could theoretically also be shared by them. So, instead of sharing a runtime, it would be better to share dependencies. That would also save space, but will ensure that your app is always running.