14:01:09 #startmeeting Fedora Flatpak Packaging SIG 14:01:09 Meeting started Mon May 15 14:01:09 2023 UTC. 14:01:09 This meeting is logged and archived in a public location. 14:01:09 The chair is kalev. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 14:01:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:09 The meeting name has been set to 'fedora_flatpak_packaging_sig' 14:01:09 #meetingname flatpak-sig 14:01:09 The meeting name has been set to 'flatpak-sig' 14:01:09 #topic Init process 14:01:38 .hello tpopela 14:01:41 tpopela[m]: tpopela 'Tomas Popela' 14:01:44 .hello otaylor 14:01:46 OwenTaylor[m]: otaylor 'Owen Taylor' 14:01:58 we should have a lot to discuss today about Owen's proposals 14:02:25 .hello jgrulich 14:02:26 JanGrulich[m]: jgrulich 'Jan Grulich' 14:03:39 I think we have almost everyone here now. yselkowitz[m] usually comes half an hour late I believe. 14:04:10 #topic Flatpaks without Modules 14:04:12 https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules 14:04:45 sooo, Owen posted the change proposal and I think it would be good to discuss this a bit 14:05:11 .hello siosm 14:05:12 travier: siosm 'Timothée Ravier' 14:05:30 👋 14:05:32 I myself think it's a major improvement over the way we do flatpaks now. Using standard koji tags makes everything so much easier to understand for most of the Fedora packagers 14:05:51 OwenTaylor[m]: are there any specific points we should talk about? 14:06:44 when looking at the proposed tag structure, I noticed two things 14:06:48 Maybe I first should ask if anybody has questions - is the general way it's going to work clear to people? I'm sure that some details will have to be worked out as we go 14:07:11 one is that there's a bit of an inconsisteny between f39-flatpak-runtime and f39-app tags naming - one has "flatpak" in it and the other doesn't 14:07:27 I filed https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/17 to track that 14:07:45 ah nice, I missed that 14:08:56 I'm fine with the second version in there where the tags have flatpaks but the %dist are without it. While the 'f38-app' thing made sense to me at the time, I certainly appreciate that consistency is good 14:09:33 I assumed '-app' means like application, it never occured to me it means just a different prefix 14:10:15 same here :) 14:10:50 +1 14:11:43 I think we can just go with f38-flatpak-app. Anybody have opinions about the two questions at the bottom of the ticket? 14:12:02 regarding the %dist tag names, there's a bit of an ordering question. Do we need the flatpak NVRs to be higher than non-flatpak ones? I think it doesn't matter, but not entirely sure 14:12:35 Fedora hasn't moved from fcXX to fXX because of ordering: f39 sorts lower for rpm ordering than fc39, I believe 14:13:45 Hmmm. I dont' thnk you want to rely on ordering, then you could accidentally pull in a non-Flatpak build that was newer. 14:15:19 My thought right now is to hav e dnf configuration includepkgs=abattis-cantarell-fonts,acl,adobe-source-code-pro-fonts,...,(rest of runtime packages),*.fc39app 14:16:04 makes sense to me 14:16:09 This is a slight variation on the way it works right now, where we have a big includepkgs that the runtime packages, and then includes the particular NVR's from the composed Flatpak modules 14:17:24 the variation being that the *.fc39app packages would be automatically depsolved and included, without an explicit include list? 14:18:11 Yeah - anything in the *.f39app (hmmm, apparently I can't keep .fc39app vs .f39app straight...) 14:18:16 would just be available for installation 14:19:02 I think that's a good simplification and makes it easier to create flatpaks 14:20:27 anyway, regarding the naming, I think I'd lean towards .fc39app just for consistency with the rest of Fedora, but I think it doesn't really matter if we wouldn't rely on .fc39app sorting higher in rpm ordering than regular packages 14:21:26 OK, I might go that way. It's probably a bigger question "why doesn't this have the c, if that C meant something, why this isn't it .fruntime39" 14:22:28 * kalev nods. 14:22:52 On a related note, I also filed https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/16 to track Michael Gruber's suggestion that we use a dist tag to distinguish the containers in Koji rather than a name like firefox-flatpak 14:23:06 .funtime39! 14:23:51 I think that makes a lot of sense 14:23:56 what do you think yourself? 14:24:01 Owen Taylor: yes, that would be amazing.. 14:24:37 from a packager's point of view, they'd do firefox rpm builds and firefox flatpak build and then they need to submit all of that to bodhi 14:25:28 if they share the name, then they could type "firefox" in the bodhi update list and then bodhi could autocomplete that with all of the various builds, including the flatpak one 14:25:52 kalev: I think my pros and cons are all based on what we do internally inside Red Hat. Pro: it's more consistent with the firefox-container thing that we have for RHEL. Con: I always forget to type 'firefox-container' into brew and wonder "OK, where are the containers?" And that's all really irrelevant for Fedora :-) 14:26:28 * kalev nods. 14:26:58 kalev: Hmm, would that work? You are thinking you could do a single cross-release update with both a Flatpak and an RPM? or just that they could choose the one they wanted without having to type something different for the flatpak? 14:28:48 bodhi can split up updates on its own, so when you file an update that has both the rpm builds and a flatpak build, then bodhi already knows that it needs to split it up into several updates (but the packager only needs to fill in the form with update notes once) 14:28:55 .hello yselkowitz 14:28:56 yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' 14:29:03 hi yselkowitz[m]! 14:30:26 kalev: You could of course do that without having a common name, but I guess having the common name encourages it. 14:30:35 * kalev nods. 14:30:56 how does the KDE runtime fit into the picture? does it need to copy all of the tag structure so that there's f39-flatpak-kde5-runtime, f39-flatpak-kde6-runtime, f39-flatpak-kde5-app, f39-flatpak-kde6-app etc tags and all of that? 14:32:08 One possible downside is that it might then be more confusing that the release numbers aren't coordinated. firefox-1.112.0-1.flatpak might contain firefox-1.112.0-4.fc38app or whatever. 14:32:55 We could go with firefox-1.1112.0-4.1.flatpak - but then of course that contains arbitrary versions of mozilla-filesystem and so forth 14:33:24 I don't think it's duplicated no. I think it's all the same tag. 14:34:13 oh, good point about versions being confusion 14:34:19 confusing 14:35:10 re the -candidate tag structure, I'd say that it's not needed because usually what it does is that it holds the builds until they are submitted to bodhi, but if they are just temporary artifacts that are never submitted, then there shouldn't be any need for that 14:35:28 We should be able to build KDE content into the same tags - I dont' think we need different builds of anything for the KDE runtime and the base runtime or for KDE apps and GNOME apps. If we did, then ew'd have the same issues with normal Fedora packages 14:36:14 Yeah, that's my genreal thinking - if we don't have a bodhi step to promote, then why would we call the target -candidate 14:37:25 we might need a flatpak specific -override tag though if we need to override some build that needs to go quickly in a flatpak runtime build, but for some reason don't want to do a global buildroot override for that 14:37:57 nice, good if we can avoid duplicating the tag structure for KDE flatpaks 14:39:02 kalev: So, basically we have some security update or bugfix that we want to build runtimes with before it goes stable? 14:39:07 but how do you deal with packages which are in one runtime and not the other but used by both gnome and kde apps? 14:40:11 yselkowitz: Hmm, so the case where there is a .fc39app build of libfoo because it's not in the GNOME runtime, but it is in the KDE runtime 14:40:22 exactly 14:40:25 OwenTaylor[m]: yes, for example firefox starts requiring new nss that's only available in updates-testing, and we want to do a runtime build that includes new nss before it goes stable