I agree with a lot of the points raised about this. Personally, I think the traditional packaging model is going to fade from prominence sooner rather than later, and KDE Neon should take steps to be ready when distros start packing up and using new and unique packaging formats.

Personally I've grown rather fond of Flatpak for the reasons mentioned in the task description (as well as a few others). It feels like there is a real community growing up around Flatpak whereas Snap is continuing to be a Canonical-only thing. I think it would be nice if we shipped Neon with Flathub out of the box rather than the Snap Store, and if we put more resources into packaging our apps on Flathub. Quite a few are there already, but I think we need more. And unlike the Snap store, getting more of our apps on Flathub benefits users in more distros because Flatpak is more widely distributed than Snap at this point.

While I haven't been in the loop much regarding the advantages and disadvantages of both packaging systems, I do know making use of Flatpak or Snaps is a good idea on the terms that we can nail the desktop integration between applications and the overall Plasma and KDE experience first time.

Fedora Silverblue did a great job with this on GNOME, so we should set our bar towards that standard while also making sure both Qt and GTK applications are fully integrated in all the ways possible from containerised applications.

As long as we keep to what Plasma is known for best with regards to theming and application-by-application integration I can see this plan coming together very nicely as long as it's all done first time and nothing major is left for post-first-release.

Yeah, regardless of whether Snap or Flatpak winds up the winner, I think it makes sense, as @cblack and @The-Feren-OS-Dev, suggest, to embrace the future and ship app user-facing apps using a containerized format. It feels like there's an emerging consensus that the future of packaging is an immutable base OS with containerized userland software installed on top. Personally I think this makes a lot of sense and solves one of the biggest problems I've always had with Linux distros--the fact that there generally wasn't an option to use a rolling release model for apps and the graphical shell (which you want to be up-to-date) but a stable/discrete release model for the base OS and its supporting software libraries. ...Otherwise known as "the way everyone else does it outside the FOSS world."

If anything, KDE Neon (and any distro, IMHO) should embrace these formats. It's not about rejecting them. We need both Discover plugins installed by default and with latest stable releases for its support libraries for both, which is a problem as is: snapdglib-qt, libflatpak and I'd say libappstream-qt as well.

Discussing supporting one or the other is besides the point. Developers will use either to ship their applications and we want all applications available in Plasma. In fact, only supporting either would mean that it could make developers package their application twice (at least), diminishing the QA to be done on the packaging itself. Or just not supporting an application, which is sad.

Transitioning from packaging debs to the newer formats for our applications is a sound first step in this venture.

In T12400#214443, @ngraham wrote:

I think it would be nice if we shipped Neon with Flathub out of the box rather than the Snap Store

We ship with both enabled. And have been for like a year!

I'm 100% with apol on this. The platform, in this instance neon, mustn't make a choice at all but ensure all options are working equally well. It is then upon the app developer to make sure they have suitably high quality offerings as flatpak or snap that integrate into the overall experience of the workspace so we can stop doing debs for those apps.
Last I checked the experience continued to lack in terms of theming integration and IPC, and at the same time I haven't seen any mails of developers asking for their flatpak or snap to be used over native packaging either. So, it looks to me that there is nothing to do for neon here, we are already willing and able.

In T12400#214512, @sitter wrote:

We ship with both enabled. And have been for like a year!

Oh good! My mistake, sorry.

Last I checked the experience continued to lack in terms of theming integration and IPC, and at the same time I haven't seen any mails of developers asking for their flatpak or snap to be used over native packaging either. So, it looks to me that there is nothing to do for neon here, we are already willing and able.

I agree with the two of you on the necessity of supporting both and improving integration regardless of Neon's stance.

I'm 100% with apol on this. The platform, in this instance neon, mustn't make a choice at all but ensure all options are working equally well. It is then upon the app developer to make sure they have suitably high quality offerings as flatpak or snap that integrate into the overall experience of the workspace so we can stop doing debs for those apps.

For 3rd-party apps, sure. However for 1st- and 2nd-party apps like Dolphin, Konsole, Okular, Gwenview, and Spectacle, there is generally a sort of shared development model such that nobody seems to feel responsible for maintaining the Snap/Flatpak/AppImage packaging. And this makes some sense given that we have the Release Service which is expected to take care of packaging. Coverage seems spotty for Snap and Flatpak though (and non-existent for AppImage): the Snap store has 95 KDE apps but many of them are out of date. Flathub's KDE apps are up to date but there are only 36 of them. It appears that you guys (the Neon team) are maintaining the Snap packaging, while @aacid (principally), @jgrulich, @mgallien, @dvratil and a few others seem to be doing the packaging on Flathub.

Perhaps the solution here is for the Release Service to take care of the Snap and Flatpak packaging to ensure 100% coverage of our apps on both the Snap Store as well as Flathub so they're first-class citizens. Because right now, if I want to replace all my distro-packaged KDE apps with Snap or Flatpak versions, I cannot. The Snap store is missing Dolphin, Discover, Elisa, Filelight, Kamoso, KInfoCenter, Konsole, KSysGuard, and System Settings, and the ones that are there are out of date (there's no 19.12 release, and some are even older). Meanwhile, Flathub is missing Discover, Gwenview, Filelight, Kamoso, Kate, KInfoCenter, Konsole, KSysGuard, Skanlite, Spectacle, and System Settings. And many of the KDE apps on Flathub show the old Oxygen icon instead of the current Breeze icon.

I agree that getting to a better place here is a prerequisite to shipping all KDE apps as Snaps or Flatpaks in Neon. Maybe we should focus on this first.

In T12400#214555, @ngraham wrote:

Meanwhile, Flathub is missing Discover, Gwenview, Filelight, Kamoso, Kate, KInfoCenter, Konsole, KSysGuard, Skanlite, Spectacle, and System Settings. And many of the KDE apps on Flathub show the old Oxygen icon instead of the current Breeze icon.

A lot of these apps require more probing into the system than Flatpak allows, like Filelight, KInfoCenter, Konsole, KSysGuard, and SySe5. Apps like these are better off being shipped as native applications rather add-ons.

In T12400#214565, @cblack wrote:

A lot of these apps require more probing into the system than Flatpak allows, like Filelight, KInfoCenter, Konsole, KSysGuard, and SySe5. Apps like these are better off being shipped as native applications rather add-ons.

That would seem to defeat the entire point of these packaging formats. If they can't handle any kind of app, why bother?

In T12400#214566, @ngraham wrote:

In T12400#214565, @cblack wrote:

A lot of these apps require more probing into the system than Flatpak allows, like Filelight, KInfoCenter, Konsole, KSysGuard, and SySe5. Apps like these are better off being shipped as native applications rather add-ons.

That would seem to defeat the entire point of these packaging formats. If they can't handle any kind of app, why bother?

Because their entire point is sandboxing, and applications like these need to be able to freely access stuff outside of their sandbox.

No, one point is sandboxing. Another is decoupling apps' release to users from the distro's own packaging release cycle. Another is providing a single packaging format for developers to target. Another is allowing developers to specify and depend on consistent library versions rather than needing to support whatever random version is in 500 distros. And so on. If these apps in question got on Flathub or the Snap store with no sandboxing whatsoever, it would still be a win over traditional distro packaging.

In T12400#214568, @ngraham wrote:

No, one point is sandboxing. Another is decoupling apps' release to users from the distro's own packaging release cycle. Another is providing a single packaging format for developers to target. Another is allowing developers to specify and depend on consistent library versions rather than needing to support whatever random version is in 500 distros. And so on. If these apps in question got on Flathub or the Snap store with no sandboxing whatsoever, it would still be a win over traditional distro packaging.

A lot of these points are targeted only for third party applications to a given platform— apps like system settings and file managers and task managers are intended to be distributed as part of the desktop they're designed to be used in. Case in point: all current atomic distros distribute system settings and file managers and task managers and the like with the same mechanism as they distribute the desktop. File managers and terminals and task managers could probably be handled with more APIs for apps like these in the future, but system settings should always be part of the desktop they're for.

In T12400#214569, @cblack wrote:

A lot of these points are targeted only for third party applications to a given platform— apps like system settings and file managers and task managers are intended to be distributed as part of the desktop they're designed to be used in. Case in point: all current atomic distros distribute system settings and file managers and task managers and the like with the same mechanism as they distribute the desktop. File managers and terminals and task managers could probably be handled with more APIs for apps like these in the future, but system settings should always be part of the desktop they're for.

Dolphin is an app that is very explicitly NOT tied to Plasma and the OS, and we want to keep it that way. Lots of people outside of the Plasma world like Dolphin, and they should be able to get it from Flatpak or Snap. BTW The point seems moot for Dolphin since there's already a Flatpak version of it. The same goes for Konsole: there is no good reason for it to be tied to a Plasma desktop and it should be a fully portable app usable in a variety of environments. This is something that it's not acceptable for us to compromise on. The same is even true of Discover, which AFAIK is used by Lubuntu now.

For System Settings, sure, that's one that only really makes sense to use in conjunction with Plasma.

In T12400#214555, @ngraham wrote:

Perhaps the solution here is for the Release Service to take care of the Snap and Flatpak packaging to ensure 100% coverage of our apps on both the Snap Store as well as Flathub so they're first-class citizens. Because right now, if I want to replace all my distro-packaged KDE apps with Snap or Flatpak versions, I cannot. The Snap store is missing Dolphin, Discover, Elisa, Filelight, Kamoso, KInfoCenter, Konsole, KSysGuard, and System Settings, and the ones that are there are out of date (there's no 19.12 release, and some are even older). Meanwhile, Flathub is missing Discover, Gwenview, Filelight, Kamoso, Kate, KInfoCenter, Konsole, KSysGuard, Skanlite, Spectacle, and System Settings. And many of the KDE apps on Flathub show the old Oxygen icon instead of the current Breeze icon.

Compared to the traditional release this needs much more insight into the single applications. For example you need to know to which interfaces the applications want to talk (for example e2cb1f8efc38cbc2e2e3ee5eaf675a5561bdaa47).
I am not thinking that the release team doesn't have amazing knowledge but I can't see how it could be done for the 120+ applications that are part of release services.

True, but that's a one-time thing for each app though, right? Once it's done, the release team mostly needs to take care of releasing it as new versions come out.

In T12400#214574, @ngraham wrote:

BTW The point seems moot for Dolphin since there's already a Flatpak version of it.

Huh, didn't know that. Looking at the manifest, it looks like it relies on communicating with a KDE-specific daemon instead of a more general-purpose file manager API provided by flatpak, which seems reasonable for its use case. Looks like it does require kio on the host instead of being able to bundle it, however.

I'm not clear on the purpose of this task. KDE neon wants to support using every package format so our users can install and use software in any format it comes in.

KDE generally should create packages in every package format so our users can run as much software as possible.

KDE neon has taken the lead in creating Snap packages of KDE software but this should be better integrated into the rest of KDE's projects. The same goes for Appimage and Flatpak, there are teams which help make those packages and they should integrate with KDE app project generally to stop having an artificial separation between app creators and distributors.

As far as I am aware our flatpaks are purely packaging formats and don't take advantage of any sandboxing features. So I don't see what is there to recommend our flatpak implementation over our snap implementation, say. But then again, that could be part of this: pushing the packaging forward.
On the other hand: has anybody asked the application developers about their opinion on this? After all, they will be expected to take on additional maintenance efforts to make sure their app continue to work well with the chosen packaging format and they might just have opinions on that.

I think this started out as the idea that Neon (not KDE in general, but Neon in particular) should be more "opinionated" with regards to which next-gen packaging format it steers users towards. If that's a no-go, then I guess there's nothing to do here, and we should just focus on increasing the coverage for our apps on Snap and Flatpak (and AppImage too, I guess?).

Personally I would like very much to use a Linux-based OS that works more like other OSs in that the base OS+the DE are on a discrete release schedule, but all apps are rolling, which is something that only seems possible with one of the next-gen packaging formats. Most contemporary distros are all rolling, or all discrete release, but not a mixture (Neon being a notable an interesting exception, but it's not rolling for all apps, just KDE apps).

If I understand "the Neon position" correctly here, Neon aims to be the base OS + Plasma desktop. The only reason it still bothers with packaging apps is because it has to because nobody is going to use an empty shell, and the Linux world isn't all app-ified yet.