Fri, Jan 17
Wed, Jan 15
Revisit for 20.04 I guess. Not much worth putting effort into this now.
Wed, Jan 8
Wed, Jan 1
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.
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?).
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 there is 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'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.
Dec 21 2019
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.
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.
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.
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."
Dec 20 2019
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.
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.
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.
Dec 18 2019
Dec 16 2019
is this not a Gnome built-in capability ?
Dec 11 2019
Dec 4 2019
Dec 3 2019
Anyway this is up now; shall we close the Phab task?
I update the text for Neon. Sorry I missed it
@jriddell I added the Made by KDE brand for neon
"Kubuntu is the Ubuntu version with KDE software by default." version -> flavour (or flavor)
This is great, Carl! Thank you so much for your work 👍 🙏
Jonathan said our writer isn't ready for this sort of spotlight IIRC. @jriddell input?
Regarding the suggestion to use ROSA image writer, this may be my American perspective creeping in, but the .ru domain name of the download links might scare off some people. Sucks, but it is what it is. I wonder if Etcher (https://www.balena.io/etcher/) might be a more neutral recommendation.
I polished a bit https://kde.carlschwan.eu/distributions.
Nov 25 2019
Nov 19 2019
The arm setup actually disappeared since (possibly wasn't carried into new server) so there are no up to date metrics. It does not really matter though since we do not have a way to pull this off for amd64. We'd require a persistent storage for the cache as nodes are largely ephemeral so result need "offsite" storage. This would be tricky to do since we currently have no space for this and the actual transfer overhead would like destroy any gains made by the cache. Plus there is of course the risk of false positives anyway. All in all no longer viable to implement.