[13:38] <ahoneybun[m]> https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpak
[13:38] <ahoneybun[m]> Fallen (@fallen:kewis.ch) first one so far.
[13:39] <Fallen> Yep, the news is out! I'm positively surprised despite the opinion.
[13:39] <Fallen> https://www.phoronix.com/news/Ubuntu-No-Flatpak-By-Default
[13:39] <Fallen> This one I dislike because the headline is wrong and misleading
[13:40] <Fallen> Well, at least misleading. It makes it seem like it applies to all variants of Ubuntu
[13:40] <ahoneybun[m]> It's misleading for sure.
[13:41] <ahoneybun[m]> I'll miss having flatpak out of the box tbh but not much I can do about that.
[13:42] <ahoneybun[m]> I have flatpak setup on my NixOS installs but never use it though.
[13:46] <Fallen> My meeting door is open any time if you want to chat about it further! What I am happy about is that we are creating focus while not affecting users who have been or want to use it.
[13:57] <ahoneybun[m]> Thank you for the offer though I'm not sure if it would change much as neither of us have the power to change this so I'd rather work on other stuff. I really need to work on the Kubuntu Manual to deal with some issues before 22.04.2.
[14:16] <Fallen> I wouldn't say that is true, but I know 22.04.2 is coming up and there is a lot to do. It can be another time :) 
[14:25] <ahoneybun[m]> It sounds like this might be effecting KDE Neon in a negative way.
[14:29] <ahoneybun[m]> Fallen (@fallen:kewis.ch) I see you are in our kubuntu-devel channel, can I tag you in a conversation about it?
[17:59] <arraybolt3[m]> o/
[18:00] <arraybolt3[m]> sitter: Since we're missing context here that we have in #kubuntu-devel, I feel it would be best for you to start so that those who read here can get the whole picture.
[18:00] <arraybolt3[m]> (Just me explaining why I'm not picking up where I left off a bit ago.)
[18:09] <aaronprisk[m]> I'd like to mention the issue of fragmentation of support. If I'm a user on a machine with both Snap and Flatpak ootb and I experience an issue, I'm probably going to seek support on Ubuntu centric resources which is going to yield me deb/snap specific support as that's what Ubuntu is built around. If we want the best support and experience for our users, having some standardization when it comes to default packing formats
[18:09] <aaronprisk[m]> is a good idea. All distros have to draw a line somewhere at some point.+
[18:09] <aaronprisk[m]> And at the same time, not actively preventing users from going out and installing flatpaks, ppa's, appimages, if they better suit their individual needs.
[18:11] <sitter[m]> hey. so. I've been taken rather by surprise by the flatpak announcement and have a hard time coming to grips with a bunch of things. chief among them being the lack of wider community involvement in the decision making both the wider kubuntu community as well as consulting with upstream on the matter. Fallen has already promised some thoughts on that so I'd wait for him to move that discussion thread forward. I feel like we've
[18:11] <sitter[m]> also already identified a bunch of things that could have gone better - that's lovely already. It's very much a done thing anyway so best we can do is learn from it. While discussing that we've also ended up on a discussion thread examining why we need to remove flatpak support from plasma discover at all and that's kind of where we left things in #kubuntu-devel to continue here. arraybolt3 pointed out that we simply don't have
[18:11] <sitter[m]> the expertise to support flatpak, that made me I asked why we can't just tell the user like we do for knewstuff. and that's kind of where we are at
[18:14] <arraybolt3[m]> (Apologies if I'm inactive for a bit, I'm dealing with a possible release blocker for 22.04.2 and so my attention has been diverted elsewhere.)
[18:14] <sitter[m]> <aaronprisk[m]> "And at the same time, not..." <- that makes perfect sense but to me it appears that removing flatpak (the infrastructure tool) seems to run counter to the intent of not actively preventing the user from doing something. it's literally putting an additional stone in the way
[18:17] <sitter[m]> to illustrate: to my mind flatpak is about equal in use to add-apt-repository. having it installed adds user experience. not having it installed is a nuisance nobody needs. that's why we have it installed by default (I hope that's why anyway ^^)
[18:17] <aaronprisk[m]> arraybolt3[m]: No worries! Knock those blockers out!
[18:21] <aaronprisk[m]> sitter[m]: I think that is a fair point. Where exactly to draw the line between included and supported is a challenging one.
[18:30] <arraybolt3[m]> <sitter[m]> "to illustrate: to my mind..." <- To add to the bit about KNewStuff, doesn't KNewStuff consist primarily (if not entirely) of themes, images, and the like, right? Not application programs. Those things are much less likely to have bugs in them than software.
[18:30] <sitter[m]> knewstuff can be anything
[18:31] <sitter[m]> e.g. plasma applets
[18:32] <arraybolt3[m]> That's still significantly less complicated than, say, an office suite or a game. To my mind, less complex and vital things are something that a user may just be like "meh, doesn't work, replace it". More complex and vital things are when you get support requests.
[18:33] <sitter[m]> as author of some of them I'd like to disagree severely on them being trivialistic ;)
[18:33] <arraybolt3[m]> Didn't know that, good to keep in mind.
[18:35] <arraybolt3[m]> I mean, it seems reasonable that a warning *should* be enough for a user to realize "here be dragons". My personal experience tells me that, at least for some warnings, users simply do not care or don't notice. I doubt that they would heed a warning like "Flatpak software is unsupported" due to how many warnings they don't heed, but I could be wrong. (Thanks balenaEtcher for focus stealing in the middle of my paragraph.)
[18:40] <sitter[m]> I do get your meaning. I am not sure why this is an issue though. as I recall we've added a priority system to discover so as long as snap>deb>* is configured the user shouldn't end up with a flatpak of say an office suite unless a flatpak repo is the sole source of that piece of software to begin with in which case there is no choice to be made anyway. IOW the user has to actively go out of their way to pick a flatpak for
[18:40] <sitter[m]> something that exists as deb and then ignore this (potentially new) warning and then encounter a problem and then decide to turn to ubuntu for support
[18:41] <arraybolt3[m]> True. But a user may not realize they're installing software from Flatpak when they see something they want in Discover and click Install.
[18:43] <sitter[m]> well, just as much as from a random PPA, no?
[18:44] <arraybolt3[m]> No, because a user has to specifically enable random PPAs.
[18:44] <arraybolt3[m]> Which is essentially what they currently have to do with Flatpak.
[18:45] <sitter[m]> I don't follow. the user has to specifically add a random PPA and the user has to specifically add a random flatpak repo. and they are not the same?
[18:46] <arraybolt3[m]> For some reason I thought Flatpak automatically used Flathub when used with Discover.
[18:47] <arraybolt3[m]> Which is a sort of automatically-enabled random PPA.
[18:47] <sitter[m]> it doesn't. that's flatpaks entire shtick
[18:48] <arraybolt3[m]> I'd have to test that, if this is the case then why is this a big deal? If Flatpak behaves as disabled by default, is it any more effort than before to enable it? The command to install it first and then add Flathub is glommed into Flathub's enabling instructions.
[18:48] <arraybolt3[m]> er, in Flatpak's enabling instructions. https://flatpak.org/setup/Ubuntu
[18:49] <arraybolt3[m]> I suppose one could use the reverse argument, if it's like this then why is it a big deal for Canonical, and why would they choose to remove it.
[18:49] <sitter[m]> I'll direct you at my ealier thoughts vis a vis add-apt-repository :)
[18:49] <sitter[m]> it's more convenience at the cost of nothing to have it pre installed
[18:50] <sitter[m]> (well the disk footprint cost of course ^^)
[18:52] <arraybolt3[m]> I'm suspecting the Flatpak system in Ubuntu must behave differently, because the rationale behind removing Flatpak by default was to avoid users unintentionally installing unsupported applications, from what I've read and heard.
[18:52] <arraybolt3[m]> I'm probably missing context.
[18:55] <aaronprisk[m]> By itself the flatpak package without remotes is pretty useless. For the average user, it needs to coupled with usable remote sources like flathub and some kind of software center connector. A user would have to do manual work to get it working anyhow even prior to this change.
[18:56] <sitter[m]> not on kubuntu. on kubuntu they just need to add the source. it's effectively the same workflow as for a ppa
[19:01] <aaronprisk[m]> Correct, one less step compared to the other flavours that either had nothing or just the flatpak package installed. At the end of the day, a quick trip to flathub and a few commands and you have full access to those applications. 
[19:02] <sitter[m]> right, but then why degrade the experience in kubuntu? it is good the way it is, a great deal of thought went into crafting it this way upstream
[19:08] <aaronprisk[m]> <sitter[m]> "right, but then why degrade..." <- Maintaining a consistent experience across all flavours. Whether you choose stock Ubuntu or one of the flavours, the process of adding flatpaks is the same. Having partial "support" in one flavour and zero support in another is not ideal and sends a message of disunity. 
[19:09] <sitter[m]> why not make the others behave properly then?
[19:09] <arraybolt3[m]> sitter: In that instance Kubuntu would have to some how influence the rest of the Ubuntu ecosystem to follow suit with them, which isn't something they have the authority to do.
[19:10] <sitter[m]> is that how kubuntu development happens now? if another flavor can't have nice things kubuntu can't either?
[19:10] <arraybolt3[m]> They could possibly convince all the other flavors and the Desktop team to follow suit, but they can't say "Ubuntu now has Flatpak enabled by default across the board."
[19:10] <sitter[m]> I am not arguing for that
[19:10] <sitter[m]> I am arguing for not degrading the plasma experience
[19:11] <sitter[m]> if you want to play the unity card
[19:11] <sitter[m]> then that is fine :)
[19:11] <Eickmeyer[m]> sitter[m]: Ok, now you're stepping into Ubuntu Studio territory too.
[19:11] <arraybolt3[m]> sitter[m]: Of course not, and no one is trying to say that. But what if a flavor wanted to include, say, an unsupported kernel by default?
[19:11] <sitter[m]> I've been here all along :)
[19:11] <arraybolt3[m]> Some things are core to the OS.
[19:11] <arraybolt3[m]> Package managers are one of them, like kernels.
[19:11] <sitter[m]> apples and oranges
[19:11] <sitter[m]> again
[19:12] <arraybolt3[m]> I don't think so. How many distros do you know that have their own specific kernel and package manager? Virtually all of the major ones, if not all of them.
[19:12] <arraybolt3[m]> (Assuming I understand correctly.)
[19:13] <Eickmeyer[m]> Sadly, Kubuntu doesn't get to dictate what goes into the Plasma experience, just like Ubuntu Studio doesn't get to dictate what goes into the Plasma experience. You'll notice that each desktop is configured completely differently and offers a completely different configuration. So, sorry, that argument doesn't hold weight.
[19:13] <arraybolt3[m]> Things at the very heart of the Ubuntu experience aren't something that one flavor can choose to go with and another one can choose to go without.
[19:13] <Eickmeyer[m]> By that, I mean to each other.
[19:13] <sitter[m]> you only have one kernel running on a system. you have a multitude of package managers. ubuntu has two as per the announcement
[19:14] <sitter[m]> Eickmeyer[m]: which argument? degrading plasma experience?
[19:14] <Eickmeyer[m]> sitter[m]: Dicatating the plasma experience to each other.
[19:15] <Eickmeyer[m]> By your argument, Ubuntu Studio should also be shipping flatpak by default.
[19:15] <sitter[m]> well, I mean I'm not dictating in general. but we have an upstream plasma experience
[19:15] <sitter[m]> if kubuntu and ubuntu studio don't want to follow that. then that is a decision that can be made. it's not like I have any power to force anyone to do anything, it's all free software
[19:16] <Eickmeyer[m]> Kubuntu, likewise, does not have an upstream Plasma experience. The default theme isn't the same as it uses a variation of Plasma Twilight.
[19:17] <sitter[m]> a theme is not the same I'm sure we can agree :)
[19:19] <Eickmeyer[m]> I'm saying that while I understand your point, I don't understand why all of the sudden, when you're absent for a long time, you all of the sudden want to be involved with Kubuntu again with this announcement. Remember, Ubuntu is a meritocracy, and keeping those merits requires sustaining contribution. That's why my questions were so directed earlier.
[19:19] <sitter[m]> oh I got that. made me feel very welcome
[19:19]  * Eickmeyer[m] always wants to get to the heart of the matter.
[19:20] <Eickmeyer[m]> It just seems, to me, this is all personal?
[19:20] <sitter[m]> well it is
[19:20] <sitter[m]> you see. I have given decades of my life to free software, kubuntu and KDE software for the longest stretch
[19:22] <sitter[m]> to see KDE features thrown out of kubuntu for no technical reasons after there were some back alley negotations where some subset of the community went sure, not understanding the consequences. that feels like a stab in the chest I gotta be honest
[19:23] <sitter[m]> and if you can't appreciate that then we really have nothing to talk about. because I come from a place of love and you questioning that hurts me more than I need to take
[19:23] <Eickmeyer[m]> Sure, sure. I just wanted to get to the heart of the matter, since this seemed to stem from somewhere very deep.
[19:24] <sitter[m]> yep
[19:24] <aaronprisk[m]> Whoa, let's pump the brakes. I want to try to stay on the technical discussion here.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a3d9cd193553a97d3d3d51bcc15e24d40df703dc>)
[19:25] <aaronprisk[m]> */sorry typo - "summary of our concerns"
[19:30] <aaronprisk[m]> sitter[m]: Thank you. I want to make sure I'm accurately representing your concerns. 
[19:30] <Eickmeyer[m]> sitter: I want to thank you as well. I just wanted to better understand your POV and the emotional perspective. I apologize for sounding otherwise.
[19:31] <Fallen> Hey folks, back from dinner and catching up. Thank you aaronprisk for holding the fort and I appreciate the summary. What I really liked is the constructive part of this conversation, it looks like we are all very interested in finding a solution. Let's continue doing that :)
[19:32] <Fallen> Starting with the second point since I think that might be easier to acknowledge:
[19:38] <Fallen> I think we can all agree more communication is better. Not looking to assign blame at this point. My lesson learned is to involve the councils more broadly when these issues come up. While generally I am in favor of having conversations in the open, as you see from the media coverage and comments on the internet I don't think it would have been smart to do so. It would drag out the news and negativity unnecessarily. I do agree that the
[19:38] <Fallen> leadership group of each flavor should be part of the conversation.
[19:40] <Fallen> When the next type of issue comes up we can have that conversation though, and consider what part of it makes sense to discuss publicly. I'm hoping we can have the next conversations more openly though and we don't have many such situations
[19:40] <Fallen> Moving on to the experience, is it fair to say that is the only concern?
[19:42] <sitter[m]> I think so
[19:45] <Fallen> Oh one more point, if as part of that council conversation it becomes clear that the council needs to involve specific individuals with expert knowledge that is certainly reasonable. 
[19:46] <Fallen> So user experience, I might have missed some of this in scrollback. I remember ahoneybun testing and not noticing a major difference. Let me check more scrollback on the remaining issues. 
[19:48] <sitter[m]> from 22.10 there definitely should be a difference. The primary point of difference is that currently adding a flatpak source and installing a flatpak is about en par with PPAs in discover. Removing flatpak means the user first needs to install that before they can then crack on with installing stuff. Which of course is the only change that is being made as per the announcement as I understand it (removing flatpak - the tool
[19:48] <sitter[m]> from the ISO)
[19:56] <Fallen> Yes, this is about removing flatpak from the default seed, and by extension also plasma-discover-backend-flatpak, because that will require flatpak to be installed. We're keeping it around for everyone who is already using flatpak, so this will in essence only affect new installs.  When someone wants to install a flatpak now, do I see correctly that they need to configure the repo first?
[19:58] <sitter[m]> that is how flatpak work, yes. you get no repo pre-configured
[19:58] <Fallen> Is the act of adding new repos similarly simple to apt installing flatpak?
[20:02] <sitter[m]> Not sure I quite understand the question. it's simpler because flatpak is already installed. so in discover you just hit a button 'add source' and paste in the repo url and then you can install stuff from there
[20:05] <Eickmeyer[m]> To interject for a moment: If it's not installed, as here in Ubuntu Studio, it's as simple as searching for "flatpak" in discover and being presented with this: 
[20:05]  * Eickmeyer[m] uploaded an image: (12KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/iVFGmfYpYgotMuelpabOYSVK/image.png >
[20:09] <Fallen> Both of you together have answered my original question, it was more about how difficult it is to get the backend and flatpak support set up, vs how difficult it is to add a repo and get a package installed. I acknowledge it is one more step that needs to be done, but I am glad they are similarly simple. It is certainly a change in user experience, though if work needs to be done to get a package installed, then I feel it is not unreasonable
[20:09] <Fallen> to require one more step. The add source button does make it seem like flatpaks are a supported and standard part of the Kubuntu experience.
[20:10]  * arraybolt3[m] wonders if there's an Add Source button in Discover for PPAs
[20:10] <sitter[m]> I think that's relegated somewhere else
[20:10] <arraybolt3[m]> I've never checked - PPAs are always things I enable from the CLI.
[20:10] <arraybolt3[m]> I'm not on a KDE system right now so I can't check.
[20:11] <sitter[m]> Fallen: Does that mean knewstuff is also getting removed though? Or is that supported? And why can we support knewstuff but not flatpak?
[20:11] <Eickmeyer[m]> > * <@arraybolt3:matrix.org> wonders if there's an Add Source button in Discover for PPAs
[20:11] <Eickmeyer[m]> There is, it opens Software Sources.
[20:12] <Fallen> Can you give me some context on knewstuff?
[20:12] <arraybolt3[m]> KNewStuff is basically a thing in KDE that can install some extra KDE add-ons (plasmoids, wallpapers, themes, etc.) that are community contributed and unsupported by both Kubuntu and KDE itself. It, however, specifically warns the user about this.
[20:13] <sitter[m]> ^ With that said, what if the flatpak integration also warned the user?
[20:17] <ogra> knewstuff -> the equivaent to gnome extensions i'd say
[20:17]  * sitter[m] uploaded an image: (676KiB) < https://libera.ems.host/_matrix/media/v3/download/kde.org/8e24bba4364c7620b4b55288353d4349fd6f429b/Screenshot_ubuntu22.04_2023-02-22_21%3A17%3A22.png >
[20:17] <ogra> (probably not as horrid as gnome extensions if you look closer)
[20:19] <Fallen> Wallpapers and themes seems somewhat different to me in use case. If there were a centralized wallpaper and theme system that Ubuntu is betting on being the most promising technology choice, then it might apply. If adding another wallpaper/theme system creates fragmentation to the same extent, it would be more likely. This is somewhat theoretical though. We can certainly explore were to draw the line further on. I don't feel that knewstuff
[20:19] <Fallen> qualifies in the same way, so that doesn't need to be removed.
[20:20] <sitter[m]> I'm more concerned about widgets. They can and do change the desktop in radical ways, in some ways more than an application would impact things
[20:20] <arraybolt3[m]> Plasmoids are more like mini-applets.
[20:20] <arraybolt3[m]> At least the ones I've used.
[20:20] <sitter[m]> basically everything in plasma (the desktop) is a plasmoid. the panel, the app launcher, the wallpaper and so on and so forth
[20:22] <Fallen> On warning the user, this is actually a good point and something I wanted to mention also: To provide that focus, flatpak should not part of the critical path when setting up or using the operating system. If there is a point in documentation that explains to the user what flatpak is, how far it is supported, and how to get it enabled, that seems completely reasonable. If this is enabled by default, or presented during the install process as
[20:22] <Fallen> a recommended option, it would be different.
[20:22] <ogra> but thats an internal desktop feature (like gnome extensions) why would that be relevant for this discussion or why would you think anyone would deny its shipment 
[20:23] <ogra> seems like an essential part of your desktop to me, not an additiona extrnal package manager 
[20:23] <ogra> +l
[20:24] <sitter[m]> we do consider all of discover an essential part of the desktop, but that will only get us hung up on semantics :)
[20:24] <ogra> heh, yeah ... 
[20:24] <Fallen> What if someone would argue to enable dnf and rpm by default, would that count in the same way?
[20:25] <sitter[m]> we do not have backends for either of those
[20:25] <sitter[m]> hypothetically yes though
[20:26] <sitter[m]> plasma's tag line is simple by default powerful when needed. that kinda informs all design decisions, such as supporting all major packaging formats so the user has a great time no matter their choice
[20:28] <sitter[m]> What I don't understand vis a vis knewstuff is: if the driving force behind the removal of flatpak is to simply not have users accidentally run afoul of unsupportable stuff then shouldn't sticking a warning like we have for knewstuff also be a sufficient solution to that?
[20:29] <sitter[m]> in a way knewstuff can create way crazier support requests and user problems because some of them sport entirely new distinct implementations of what a panel is for example
[20:29] <sitter[m]> others can crash your entire desktop
[20:30] <sitter[m]> (which of course is why we put that warning on there ;))
[20:30] <ogra> but thats still an internal default feature of your desktop ... 
[20:31] <ogra> you wouldnt blieve how many gnome extensions have crashed my desktop since they exist ... yet any browser can just install them ... 
[20:31] <sitter[m]> I find that perplexing, so if we made flatpak an internal default feature you wouldn't remove it?
[20:32] <ogra> if flatpak would have been developed as an essential part of your desktop, how could anyone ask ?
[20:32] <sitter[m]> Maybe I am not getting the announcement correctly. But flatpak isn't being removed because it is optional, is it? It's being removed because ubuntu cannot support/help with rando flatpaks the user might end up installing
[20:32] <ogra> but we're talking about a additional external package manager here, not about a central desktop part
[20:33] <ogra> a package manager for which you culd potetially add a checkbox to your installer to have it downloaded and installed ... the desktop still functions without it though 
[20:33] <sitter[m]> and I am, kind of surprising to myself as well, telling you that there is a much much much much more impactful package manager  at the heart of plasma that semingly is not a problem
[20:34] <ogra> "at the heart of plasma" ... it has been a part of it developed for it etc etc 
[20:36] <sitter[m]> how does that affect "receives the majority of attention when it comes to resolving issues in software packages." (quoting the announcement here)
[20:36] <aaronprisk[m]> Where do applications/themes/etc from knewstuff reside? ~?
[20:36] <sitter[m]> store.kde.org
[20:37] <sitter[m]> well, actually it's a bit more complicated than that
[20:37] <sitter[m]> technically anywhere on the interwebs, but the majority (perhaps even all) come from the store
[20:37] <aaronprisk[m]> As in, where in the OS do they exist once downloaded?
[20:37] <sitter[m]> .local
[20:37] <Eickmeyer[m]> Specifically ~/.local
[20:38] <ogra> i didnt write the announcement and i dont really want to fight this argument but a package manager that can install random desktop software of any kind is surely something different from a built-in desktop extension manager 
[20:40] <sitter[m]> ogra: we can certainly agree that they are different :) my point is that the arguments raised in the announcement for removing flatpak equally and perhaps even more so apply to knewstuff
[20:40] <aaronprisk[m]> In that case, I don't think it's accurate lumping it in with rpm, snap or flatpak as a true package manager. It's more akin to gnome-extensions like ogra said, albeit a more powerful one.
[20:40] <sitter[m]> aaronprisk: if you add a flatpak source to discover those too go to .local?
[20:40] <sitter[m]> well, ?! really
[20:41] <sitter[m]> 😕
[20:42] <aaronprisk[m]> Not in the conventional Linux package sense. I understand what you're getting at, and I'm not implying anything negative about knewstuff, I just don't think it's a 1:1 comparison. 
[20:42] <sitter[m]> you'll have to elaborate the difference for me. I am not seeing it
[20:44] <aaronprisk[m]> Sure, for example, I wouldn't say that npm and dnf are the same even though they are both technically package managers. They share some commonalities, but they have different goals and operate at different levels. 
[20:46] <sitter[m]> Right, but what's different about them?
[20:47] <aaronprisk[m]> Their scope and function within the operating system.
[20:47] <sitter[m]> What?
[20:48] <sitter[m]> Sorry, I'm being daft I'm sure
[20:49] <ogra> they operate on an OS level ... install stuff system wide, break your existing installs in a system level if you use them wrong etc ...
[20:50] <ogra> s/in a/on a/
[20:50] <sitter[m]> but flatpak doesn't do that?
[20:51] <sitter[m]> Let's walk this back a moment. We may be talking past each other here
[20:51] <ogra> it does not allow system-wide installs of apps ? thats news to me 
[20:51] <sitter[m]> not the way discover adds sources it doesn't
[20:52] <sitter[m]> I was asking how knewstuff is different from flatpak. The conclusion was it must be different because it's not in .local. Flatpak (by discover defaults at least) installs to .local as well. So how are they different
[20:53] <ahoneybun[m]> Discover installs them as user not system which does that.
[20:53] <ogra> can i do "sudo flatpak install foo.bar.baz" with knewstuff in kubuntu ? 
[20:54] <arraybolt3[m]> ogra: To clarify, I believe you *can* install a Flatpak system-wide, but you can also install it for only just one user. As opposed to apt and Snap, which both only do system-wide installs.
[20:54] <arraybolt3[m]> (Here's hoping I'm right about Snap only doing system-wide installs...)
[20:54] <ogra> you are 🙂
[20:55] <sitter[m]> ogra: yup. it's called kpackagetool5 you'll need to chain it from curl though
[20:55] <sitter[m]> since that is your argument though
[20:55] <sitter[m]> what makes npm different from flatpak?
[20:55] <sitter[m]> (your argument is silly is what I'm saying there ;))
[20:55] <arraybolt3[m]> npm isn't installed by default on any version or flavor of Ubuntu though.
[20:56] <arraybolt3[m]> That I'm aware of.
[20:56] <sitter[m]> yup. but knewstuff is
[20:56] <sitter[m]> my argument is knewstuff = npm = flatpak = gem = pip = whatever
[20:56] <sitter[m]> they all do the same stuff
[20:56] <ogra> sitter[m], right, but that curl command is probably not commonly spread across blogs and whatnot ... while a "add this flatpak repo system-wide and run ... sudo flatpak install ..." might be rather common ... this is not about discover, not about GUI integration but about a package manager 
[20:56] <ahoneybun[m]> sitter what if Kubuntu makes a blog post about adding flatpak with a link to the announcement about removing it?
[20:57] <ahoneybun[m]> But with those disclaimers about not being supported officially?
[20:57] <sitter[m]> ahoneybun: I mean that'd be lovely but it's in conflict with that announcement which is what the entire argument is about
[20:57] <sitter[m]> e.g. earlier I said we can just slap a warning on discover "yo, this is unsupported territory"
[20:58] <ahoneybun[m]> I know but it's to let users know that they could use it if they need and break it that it is still possible to use flatpak even with this change.
[20:58] <sitter[m]> and that is how we ended up on the knewstuff discussion. because fundamentally that is what we do with knewstuff and that somehow magically is fine and so far I haven't really grasped why that is fine but flatpak is not
[20:59] <ahoneybun[m]> I think the difference might be that snaps are part of the Ubuntu experience and the flavors are meant to extend it with your desktop of choice?
[20:59] <ahoneybun[m]> I might be reading it incorrectly though.
[21:00] <sitter[m]> sure. but that doesn't conflict with having flatpak installed :)
[21:00] <arraybolt3[m]> ahoneybun[m]: ?
[21:00] <arraybolt3[m]> I missed something here.
[21:00] <ahoneybun[m]> I most likely missed something to be honest. I'm trying to multitask and it's not working well.
[21:01] <arraybolt3[m]> The question is, how is knewstuff and Flatpak different. I don't think Snap has anything to do with it.
[21:01] <arraybolt3[m]> (Though I've brought up Snaps a few times for other aspects of the discussion.)
[21:01] <arraybolt3[m]> ahoneybun[m]: Heh, I'm doing the same thing
[21:03] <ahoneybun[m]> arraybolt3[m]: You
[21:03] <arraybolt3[m]> Perhaps it would be doable to make a list of "things a package manager does", and a list of "things a desktop extender does", and then see how closely Snap, Flatpak, KNewStuff, and GNOME Extensions match those things.
[21:03] <ahoneybun[m]> You're doing better then I am.
[21:03] <arraybolt3[m]> ahoneybun[m]: That may be because I'm nearly letting things everywhere else fall through the cracks 🤣
[21:04] <ogra> sitter[m], the difference is that one tool can operate on a system level when invoked differently and will be used that way for sure 
[21:06] <arraybolt3[m]> I mean, there's something about KNewStuff's behavior that *feels* different than Flatpak's behavior, but I can't quite put my finger on why, and sitter has a good point IMO. Personally I still think that Flatpak would cause support trouble because it's more well-known, but then again is well-known-ness a good reason for a decision like this? Personally I think maybe it is but it still seems a bit... incorrect.
[21:06] <sitter[m]> ogra: so the point of contention is the CLI executable?
[21:06] <arraybolt3[m]> I still stand by my "this would make life misery for IRC supporters", but I'm also understanding the other side of the coin.
[21:06] <arraybolt3[m]> s/would/could/
[21:06] <ogra> sitter[m], no, the potential impact on the plumbing layer 
[21:07] <sitter[m]> ogra: but discover's use of flatpak doesn't impact the plumbing layer?
[21:07] <ogra> but flatpaks existence does !!
[21:07] <ogra> it has nothing to do with discover 🙂
[21:07] <sitter[m]> you've lost me again
[21:08] <arraybolt3[m]> ogra: Keep in mind that technically while we don't support Flatpaks, the Flatpak system itself is part of the Ubuntu archives and we technically *do* support that.
[21:08] <ogra> i undrstand that discover will suffer from removing flatpak ... but the discussion is around flatpak, not discover
[21:08] <sitter[m]> how does flatpak's existence impact the plumbing?
[21:08] <arraybolt3[m]> At least the part of the discussion I was in revolved mostly around Discover.
[21:08] <sitter[m]> I appreciate that but you'll have to forgive me that my entry point and why I even care is because of discover :)
[21:09] <ogra> it allows you to do things on a system-wide level even if i remove plasma from the machine there will be flatpak ... it will be different from any other *buntu i remove the desktop from ....
[21:09]  * arraybolt3[m] wishes there was a magic button that would insert all existing context into everyone's brain, including mine, who missed some of it :P
[21:09] <ogra> lol, yeah
[21:10] <sitter[m]> ogra: it doesn't though if you take the exectuable out of the equation
[21:10] <sitter[m]> no flatpak binary = no silly commands users can run = only discover = only stuff in ~/.local happens
[21:10] <sitter[m]> which is why I asked the question if the exectuable is the point of contention
[21:11] <arraybolt3[m]> sitter: Are you suggesting the possibility that perhaps Discover could include Flatpak as a module of its own, locked away from the user unless they use it via Discover?
[21:11] <sitter[m]> yes
[21:11] <arraybolt3[m]> Because that sounds really cool to me and like it might solve a lot of the problem.
[21:11] <arraybolt3[m]> At least for Kubuntu.
[21:12] <sitter[m]> but that requires engineering. while my original proposal, which I still do not understand why it is being discounted, of adding a warning is way cheaper to achieve
[21:12] <sitter[m]> heck. we could even wrap around the flatpak binary and throw up a y/n question for the user "this is unsupported, are you sure you want this?"
[21:13] <arraybolt3[m]> sitter: One can't exactly add a warning to the Flatpak binary though. And many Linux users don't even use Discover and will install stuff via the CLI.
[21:13] <arraybolt3[m]> I mean we could add a warning but that's extra dev work that we'd like to avoid.
[21:13] <arraybolt3[m]> s/exactly/easily/
[21:13] <sitter[m]> and exactly those users we want to safe from flatpak!
[21:13] <sitter[m]> warnings are cheap
[21:15] <arraybolt3[m]> I'm a bit too hungry to proceed, but I think we've come up with some good ideas and possibly some solutions to at least make similar events less painful. Thanks for a good discussion :)
[21:15]  * arraybolt3[m] buries head into food-making and 22.04.2
[21:15] <sitter[m]> thanks arraybolt3 enjoy your food :)
[21:16] <Fallen> So plasma-discover-backend-flatpak currently depends on the flatpak package. Are you saying that a viable solution to you would be an alternative backend that puts a warning when attempting to add a flatpak source, and if the user proceeds then flatpak would be installed and the user can proceed?
[21:18] <arraybolt3[m]> Fallen: I really hope you're mentioning that because yo uthink that's a good idea, because that sounds even easier, more efficient, and like something I wouldn't mind trying to put together and contribute if possible.
[21:20] <Eickmeyer[m]> Just FYI, right now, Discover's packagekit backend has no method for displaying dialogues, so installing a package that has an interactive dialog that requires user input merely inputs the defaults and displays no warnings to the user.
[21:21] <arraybolt3[m]> Eickmeyer[m]: I think that would only affect it if "sudo apt install flatpak" triggered a debconf prompt, which I don't think is the idea.
[21:21] <arraybolt3[m]> (So much for me being done :P)
[21:21] <Eickmeyer[m]> arraybolt3[m]: Correct, but that would be the same as installing the backend for discover as well.
[21:21] <sitter[m]> yeah that wouldn't really improve the situation
[21:22] <arraybolt3[m]> I thought the idea was, if the user goes to add a Flatpak source, Discover would have built-in code that would install flatpak upon adding the first source, but it would prompt the user before doing that.
[21:23] <ogra> does kubuntu have some kind of first-start wizard ? 
[21:23] <sitter[m]> at that point the user can just click the "install flatpak backend" button I'm sure :)
[21:23] <sitter[m]> Fallen: I find that hard to answer without having fully explored what the difference between knewstuff and flatpak considering the motivations from the announcement
[21:23] <arraybolt3[m]> ogra: No, though KDE 5.27 has one and that will probably end up in Kubuntu in the future.
[21:23] <arraybolt3[m]> I would guess.
[21:24] <ogra> well, suc a wizard could just have a button 🙂 but if it isnt there right now that wont help 
[21:24] <Fallen> Just trying to find out where folks draw the line. I'm not really a fan of warnings, as it unnecessarily creates a negative experience. If it is not available and people make an active choice to install flatpak because they believe in the technology, they've made an informed choice and have a chance to learn about the tradeoffs. If there is messaging that discourages it, this has a negative connotation, and seems even more like an attempt to
[21:24] <Fallen> discredit, which is not the intetion. 
[21:27] <ahoneybun[m]> arraybolt3[m]: we could easily add one about Flatpak.
[21:27] <sitter[m]> What I don't get is why it matters whether flatpak is installed or not. The user has to opt into a flatpak repo anyway. So it is already opt-in. Right now. Today. If the CLI exectuable is the point of contention there are ways around that, but ogra then said something about plumbing that I didn't quite get
[21:28] <sitter[m]> Not a fan of the wizard idea BTW. Then we'd be advertising flatpaks, that kinda runs counter to the point of this entire move, no? :D
[21:28] <ogra> sitter[m], well, it is a cmdline tool as well as a piece of your package manager ... as i said above, if i remove all GUI from my install i'll still hve that additional package manager around 
[21:28] <ogra> this is what i mean by affecting the plumbing layer ... 
[21:28] <sitter[m]> ogra: yes. but say you get a warning when you run said package manager
[21:29] <ogra> in my terminal ? 
[21:29] <arraybolt3[m]> I think that may have been a misunderstanding by Eickmeyer, running "sudo apt install flatpak" just does it.
[21:29] <sitter[m]> yup
[21:29] <sitter[m]> or you move it to libexec, or for all I care discover just embeds the bloody thing and we delete it from disk :'D
[21:29] <Eickmeyer[m]> arraybolt3[m]: No, my idea was if there was a warning along with it, that's all.
[21:30] <arraybolt3[m]> Oh, OK.
[21:30] <Eickmeyer[m]> Purely hypothetical.
[21:31] <ogra> yeah, there is not one today and there souldnt be ... sudo apt install flatpak is definitely a concious thing i did because i want flatpak ... 
[21:31] <sitter[m]> so is setting up the repo
[21:32] <sitter[m]> I don't get why we are hung up on it mustn't be installed. The user literally has to opt into using it
[21:39] <aaronprisk[m]> I'll flip the question, why is critical that it be installed by default when we've already established that it's lacking the additional components and remote sources to actually be of practical use to a new user? As Fallen said, one additional step does not seem like a degradation of user experience.
[21:40] <sitter[m]> Because paper cuts matter. One additional thing you have to do is a paper cut
[21:40] <arraybolt3[m]> And it was kind of already in Kubuntu and then was removed out of it by agreement.
[21:41] <sitter[m]> That too, it is degrading things
[21:44] <aaronprisk[m]> That's largely subjective. People said not having desktop icons on by default in GNOME 3 was a degradation.
[21:45] <sitter[m]> apples and oranges
[21:48] <Fallen> I need to head out for today folks, I'm sorry I can't be here for the next part. aaronprisk will be here for a short while longer, and ilvipero will be in a few hours later. If y'all could converge towards a few potential solutions that would be great. I acknowledge we might not arrive at a solution that will be satisfactory to everyone, and remember sometimes degrading a user experience on one end improves it on the other end.
[21:48] <Fallen> I'd also recommend maybe we take some time to process before continuing :)
[21:49] <sitter[m]> very good idea :)
[21:49]  * ogra notes that arraybolt3[m] mentioned food above and that he is hungry since he read that ... 
[21:49]  * ogra goes cooking ...
[21:51]  * Eickmeyer[m] forgot to eat
[21:52]  * arraybolt3[m] eats mashed potatoes, then consumes the plate
[21:59] <Eickmeyer[m]> > * <@arraybolt3:matrix.org> eats mashed potatoes, then consumes the plate
[21:59] <Eickmeyer[m]> crunchy
[22:00] <aaronprisk[m]> > * <@arraybolt3:matrix.org> eats mashed potatoes, then consumes the plate
[22:00] <aaronprisk[m]> Taking "clean your plate" to a whole new level.
[22:01] <arraybolt3> Meh, it was a paper plate. Much more chewy and tough than expected. 0/10 would not recommend.
[22:02] <Eickmeyer[m]> arraybolt3: Lots of fiber.
[22:02] <arraybolt3> rofl
[22:12] <ogra> it's all a matter of the sauce !!
[22:21]  * arraybolt3[m] applies Chinese mustard to a paper plate and takes a bite, nope still horrible