16:30:06 <travier> #startmeeting fedora_coreos_meeting
16:30:06 <zodbot> Meeting started Wed Jan 26 16:30:06 2022 UTC.
16:30:06 <zodbot> This meeting is logged and archived in a public location.
16:30:06 <zodbot> The chair is travier. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:06 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:11 <travier> #topic roll call
16:30:16 <travier> .hello siosm
16:30:17 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:30:49 <travier> #chair siosm
16:30:49 <zodbot> Current chairs: siosm travier
16:31:01 <travier> #undo
16:31:01 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fb5f543c080>
16:31:07 <travier> #topic roll call
16:31:12 <davdunc> .hi
16:31:13 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:31:25 <saqali> .hi
16:31:26 <zodbot> saqali: saqali 'Saqib Ali' <saqali@redhat.com>
16:31:29 <jlebon> .hello2
16:31:30 <lorbus> .hi
16:31:30 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:31:31 <travier> #chair davdunc
16:31:31 <zodbot> Current chairs: davdunc siosm travier
16:31:33 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:31:35 <travier> #chair jlebon
16:31:35 <zodbot> Current chairs: davdunc jlebon siosm travier
16:31:36 <dustymabe> .hi
16:31:37 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:38 <travier> #chair lorbus
16:31:38 <zodbot> Current chairs: davdunc jlebon lorbus siosm travier
16:31:40 <travier> #chair dustymabe
16:31:40 <zodbot> Current chairs: davdunc dustymabe jlebon lorbus siosm travier
16:31:47 <travier> #chair saqali
16:31:47 <zodbot> Current chairs: davdunc dustymabe jlebon lorbus saqali siosm travier
16:33:09 <jaimelm> .hello2
16:33:10 <zodbot> jaimelm: jaimelm 'Jaime Magiera' <jaimelm@umich.edu>
16:33:39 <bgilbert> .hi
16:33:40 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:34:06 <travier> #chair jaimelm bgilbert
16:34:06 <zodbot> Current chairs: bgilbert davdunc dustymabe jaimelm jlebon lorbus saqali siosm travier
16:34:45 <travier> Alright, let's start
16:34:50 <travier> #topic Action items from last meeting
16:35:00 <travier> No action from last time as far as I can see
16:35:16 <lucab> .hi
16:35:17 <zodbot> lucab: lucab 'Luca BRUNO' <lucab@redhat.com>
16:35:20 <travier> Any topic we should discuss first?
16:35:23 <travier> #chair lucab
16:35:23 <zodbot> Current chairs: bgilbert davdunc dustymabe jaimelm jlebon lorbus lucab saqali siosm travier
16:35:31 <aaradhak[m]> .hi
16:35:31 <zodbot> aaradhak[m]: Sorry, but user 'aaradhak [m]' does not exist
16:36:09 <miabbott> .hello miabbott
16:36:10 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:36:12 <aaradhak> .hi
16:36:13 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:36:18 <travier> #chair miabbott aaradhak
16:36:18 <zodbot> Current chairs: aaradhak bgilbert davdunc dustymabe jaimelm jlebon lorbus lucab miabbott saqali siosm travier
16:36:24 <travier> #topic Support GRUB bootloader password
16:36:36 <travier> #link https://github.com/coreos/fedora-coreos-tracker/issues/134
16:36:54 <dustymabe> i tagged this for the meeting to see if anyone wanted to pick it up
16:37:11 <dustymabe> looks like miabbott is indicating some desire for it downstream
16:37:37 <miabbott> <BIG CUSTOMER> has been asking for it and our RHCOS PM is getting pressure to make it available
16:38:07 <dustymabe> miabbott: thanks for the context
16:38:22 <travier> miabbott: said like that, we should tack a RH engineer to work on it :)
16:38:29 <travier> task*
16:38:41 <ravanell_> .hi
16:38:43 <zodbot> ravanell_: Sorry, but user 'ravanell_' does not exist
16:38:57 <dustymabe> That's mostly it for this topic. We can move on. Just wanted to raise awareness.
16:39:04 <travier> ok
16:39:10 <miabbott> travier: yeah, it may just come down to that
16:39:24 <travier> #topic Project Updates for Community Outreach and Testing for .ign/.bu Changes
16:39:31 <travier> #link https://github.com/coreos/fedora-coreos-tracker/issues/799
16:39:40 <travier> jaimelm: Do you have updates here?
16:40:11 <miabbott> #chair ravanell_
16:40:11 <zodbot> Current chairs: aaradhak bgilbert davdunc dustymabe jaimelm jlebon lorbus lucab miabbott ravanell_ saqali siosm travier
16:40:41 <jaimelm> Not no. Been out of the loop since before Christmas.
16:41:30 <travier> I don't think we've had feedback that the change was confusing. Was this also about editor support?
16:42:04 <dustymabe> travier: I think so
16:42:19 <jaimelm> yes
16:42:33 <jaimelm> I generated notes but need to pr them
16:42:49 <dustymabe> jaimelm: mind updating the ticket with the more focused scope?
16:43:04 <jaimelm> yeah
16:43:31 <travier> Maybe we should focus on a few selected popular editors (vim, nano, emacs, vscode) and call it done?
16:44:01 <jaimelm> I did those four a few others. I do think we should limit it and/or crowdsource the rest.
16:44:06 <dustymabe> +1
16:44:44 <travier> great!
16:45:31 <travier> #topic During major version rebases, align FCOS testing stream with GA date
16:45:39 <travier> #link https://github.com/coreos/fedora-coreos-tracker/issues/1024
16:45:50 <travier> I think we are ready now to talk about this one
16:46:52 <travier> The general idea is to try to have a testing release with the Fedora new release content on GA date
16:47:25 <dustymabe> correct
16:47:35 <travier> I don't think we've had that much trouble with the F35 rebase given the preparation work looking at the changes for 35
16:47:51 <dustymabe> yes - and also we have a rawhide stream now
16:47:53 <jlebon> yeah, preparation is key
16:47:55 <jaimelm> As long as that prep process continues, seems like a good plan'
16:48:38 <travier> Any objections?
16:48:48 <dustymabe> of course this is our guidance/goal, if we don't meet it because we're shielding users from something that popped up, it's not a bad thing
16:49:05 <jlebon> beta should be pretty frozen even a week before so `next` is already a good representation of what GA will be. so in that sense, GA is about promoting `next` to `testing`
16:49:27 <jlebon> now, if there are exceptions and respins, we'll have to evaluate how those affect the plan
16:49:35 <dustymabe> true, though sometimes there are some last minute additions
16:49:42 <dustymabe> but always happen the week before
16:49:47 <dustymabe> so we could respin `next`
16:50:00 <dustymabe> to match what will be delivered in `testing` on that next tuesday
16:50:04 <jlebon> yeah. and in general, i think those should be low risk by design
16:50:39 <dustymabe> one thing to keep in mind I guess, is that `next` won't always be a 1:1 comparison for `next`
16:50:44 <dustymabe> sorry for `testing`
16:50:58 <dustymabe> we may be experimenting in `next` and so might not be a perfect canary
16:51:03 <dustymabe> but usually that is the case
16:51:13 <dustymabe> +1 for this change - want to do a #proposed and we can vote?
16:51:16 <jlebon> indeed
16:52:09 <travier> #proposed For the Fedora 36 rebase, we will try to align the testing release including the new content with the F36 GA date.
16:52:18 <dustymabe> ack
16:52:28 <travier> +1
16:52:37 <davdunc> +1
16:52:46 <jlebon> ack
16:53:41 <bgilbert> +1
16:53:50 <jlebon> would say "aim to align" instead of "try to align" to be more optimistic, but cool as is :)
16:53:59 <travier> #agreed For the Fedora 36 rebase, we will aim to align the testing release including the new content with the F36 GA date.
16:54:13 <travier> #topic tracker: Fedora 36 changes considerations
16:54:20 <travier> #link https://github.com/coreos/fedora-coreos-tracker/issues/918
16:54:56 <travier> This is the tracker issue for Fedora 36 changes. Help looking at those to prepare for the rebase is appreciated!
16:55:24 <travier> Feel free to pick up a change and look at it to make sure it does not have negative impact on FCOS
16:56:07 <dustymabe> yeah - I'll re run the script to update the list too. We'll try to discuss these during our video meeting next week! First meeting of the month!
16:56:38 <jaimelm> Oh right.
16:56:57 <lucab_> some of those have been deferred from F35, so we are did the work for them (e.g. openssl3)
16:57:10 <lucab_> s/are/already/
16:57:40 <dustymabe> lucab_: indeed
16:58:10 <dustymabe> I'll go through and mark it with a green check
16:58:18 <travier> if there is nothing I'll move to the last topic
16:58:21 <dustymabe> that one does link to the previous open (now closed) issue
16:58:26 <travier> nothing else*
16:58:40 <dustymabe> the "Remove nscd" does as well
16:58:45 <dustymabe> travier: +1
16:59:08 <travier> #topic Consider proposing Fedora policy prohibiting scriptlets from writing to /var
16:59:11 <travier> #link https://github.com/coreos/fedora-coreos-tracker/issues/1067
16:59:44 <travier> Does anyone wants to introduce this one?
16:59:48 <travier> want*
17:00:04 <bgilbert> I can take it
17:01:00 <bgilbert> on multiple occasions, we've had breakage when new package versions update their scriptlets to write to /var
17:01:19 <bgilbert> the most recent one was authselect, which wanted to perform a config migration and use /var to track the state of that
17:01:50 <bgilbert> in rpm-ostree-land, that's a non-starter, because scriptlets are run server-side, where there's no node-specific /var
17:02:18 <bgilbert> so we end up going to the package maintainer and asking them to please not do that.  and often they're surprised, because Fedora packaging policy and other docs don't mention this constraint.
17:02:44 <dustymabe> bgilbert: yes. It puts us in a tough position.
17:03:04 <bgilbert> we have tools like the `rawhide` stream and baking the upcoming Fedora major in `next`, which helps us catch these things most of the time
17:03:26 <bgilbert> though of course it can also happen with regular package updates in stable Fedora releases
17:03:47 <copperi[m]> Maybe creating a doc would help best ?
17:04:12 <bgilbert> so the ticket proposal is: if we think that packages should generally not write to /var (with an exception for a particular subdir not further discussed here), should we advocate for changing Fedora packaging policy to reflect that?
17:04:38 <jlebon> i expect some pushback, but i think we should try this
17:04:41 <jaimelm> Looking down the road, are there any reasons the Packaging Committee might not like the idea? Seems worth pondering.
17:04:57 <bgilbert> that would a) provide better docs/notice to packagers, and b) allow automation in Fedora to start checking for this
17:05:05 <jaimelm> I think it's helpful going into a proposal knowing how it might get shot down
17:05:31 <jlebon> i suspect a *lot* of packages would be affected, so it might have to be in phases
17:05:53 <dustymabe> bgilbert: I agree I think we should try it. jaimelm we have to have strong justification to convince people
17:06:01 <lucab_> I'm skeptical that we could get a policy ban in, because of fundamental tools like 'alternatives' (or similar). I'd aim for a strong recommend.
17:06:10 <travier> That probably won't be a hard pull thing but more of a let's get to it objective
17:06:29 <bgilbert> also it'd be good to have concrete example code for what packages should do instead
17:06:35 <jaimelm> ^^
17:06:47 <jaimelm> maybe more than one
17:06:55 <jaimelm> pick a couple use cases
17:07:03 <bgilbert> +1
17:07:19 <copperi[m]> 👍️
17:07:21 <jlebon> most /var things should just use tmpfiles, which i think is already in the guidelines
17:07:40 <jlebon> the big one is actual node-specific logic like migrations, which packagers would have to relearn
17:07:44 <jlebon> to e.g. use a systemd service
17:08:21 * dustymabe also notes that containers don't have systemd typically, so that has to be considered
17:08:44 <travier> usually container don't have state in /var either
17:08:52 <jaimelm> true
17:09:00 <dustymabe> yeah, I guess containers typically don't `dnf update`
17:09:24 <travier> I don't see what could block that. This will improve the state of things for IoT, Silverblue/Kinoite as well
17:10:20 <dustymabe> not hearing much oposition.. #proposed?
17:10:25 <travier> Something that would be great would be to have dnf progressively enforce that by running the scriptlets via systemd-run with RO mounts but that's a bigger change
17:10:26 <jaimelm> yeah
17:10:32 <copperi[m]> dustymabe: I have seen quite a few containers update in build state
17:10:44 <lucab_> I'm not sure if it is unrelated or a pre-req, but we there are also packages shipping content in /var (e.g. vagrant)
17:10:52 <lucab_> s/we//
17:11:16 <jlebon> maybe first stage would be a CI run in src.fp.o and bodhi which warns if if detects /var writes
17:11:31 <dustymabe> lucab_: but they aren't trying to touch it in scriptlets?
17:11:57 <travier> #proposed We will submit a Fedora packaging policy change to the FPC to strongly recommend that scriplet do not write content in /var
17:12:00 <lucab_> dustymabe: I didn't check, hopefully not
17:12:00 <jlebon> lucab_: those should be handled by rpm-ostree
17:12:24 <jlebon> but yeah still, ideally they use tmpfiles so we don't have to convert for them
17:12:34 <bgilbert> I'd suggest s/to the FPC// s/submit/pursue/
17:12:43 <bgilbert> we can hash out process details as we go
17:12:47 <dustymabe> travier: should we shoot for "deny" and settle for "strongly recommend" later?
17:12:56 <lucab_> ok, let's not drag that in then
17:13:00 <bgilbert> I think the main value here is to get a sense of the goal
17:13:05 <dustymabe> +1
17:14:08 <travier> #proposed We will pursue a Fedora packaging policy change to strongly recommend that scriplet do not write content in /var
17:14:34 <travier> we can add the two levels (recommend / deny) into the proposal
17:14:35 <jlebon> +1
17:14:37 <bgilbert> +1
17:14:38 <dustymabe> ack
17:14:39 <jaimelm> ack
17:14:40 <lucab_> ack
17:14:41 <copperi[m]> +1
17:14:43 <travier> +1
17:14:50 <travier> #agreed We will pursue a Fedora packaging policy change to strongly recommend that scriplet do not write content in /var
17:14:55 <dustymabe> if we have time maybe we should discuss lua too
17:15:35 <travier> that would be good but maybe we should make two separated discussion as this one will get much more pushback
17:15:43 <dustymabe> oh yeah
17:15:50 <dustymabe> it would be a different proposal
17:15:58 <dustymabe> i mean "if we have time" in the meeting today
17:16:23 <lucab_> is the "agreed" an action item for bgilbert? or somebody else?
17:16:35 <jaimelm> bgilbert I would assume
17:16:38 <bgilbert> I'm not planning to work on it, no :-)
17:16:42 <jaimelm> oh
17:16:43 <jaimelm> ha
17:16:49 <travier> The Lua would probably end-up being a "if you use Lua for scriplets, warn rpm-ostree first!"
17:17:09 <jaimelm> well, the idea of getting 1-3 examples prepped seems a good place to start.
17:17:15 <jaimelm> can we distribute the love on that?
17:17:17 <dustymabe> I can add it to my list of things I never get to
17:17:20 <travier> I can work on Change request and docs PR
17:17:29 <dustymabe> travier: ❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️
17:17:34 <jlebon> travier++
17:17:42 <bgilbert> travier++
17:17:53 <travier> (this gets me badges :D)
17:18:02 <jlebon> dustymabe: haha.  sadly, i have a list like that too
17:18:03 <lucab_> a badger!
17:18:27 <dustymabe> let's hit lua real quick.. mind if I set the topic?
17:18:34 <travier> go ahead
17:18:43 <dustymabe> #topic lua: either support it or change policy
17:18:45 <travier> (but let's keep some time for OD too)
17:18:54 <dustymabe> basically we've been in the middle for a long time
17:19:09 <dustymabe> we try to get people to change their scriptlets OR
17:19:21 <dustymabe> we add an exception and hardcode an alternative in bash (that gets stale)
17:19:39 <dustymabe> we either need to do the work to fully support it
17:19:50 <dustymabe> OR pursue a policy to disallow it in Fedora
17:20:11 <jlebon> doing the work would require librpm providing an API for it
17:20:13 <dustymabe> The middle ground approach just causes needless work for us periodicially
17:20:30 <jlebon> if we had that, we could add support for it in rpm-ostree
17:21:01 <dustymabe> jlebon: is that something librpm is willing to provide (i.e. just needs someone to work on it) or are they opposed?
17:21:14 <lucab_> #link https://github.com/coreos/rpm-ostree/issues/749
17:21:19 <travier> was the change in rpm not enough to make it work in rpm-ostree?
17:21:20 <jlebon> more of the latter
17:21:30 <dustymabe> so they are opposed
17:21:33 <jlebon> https://github.com/rpm-software-management/rpm/issues/1273
17:21:48 <jlebon> https://github.com/rpm-software-management/rpm/issues/1273#issuecomment-996519896
17:21:54 <travier> I don't think we will ever be able to get the "ban lua" change accepted. It's too useful for some packages in Fedora
17:22:23 <travier> https://github.com/rpm-software-management/rpm/pull/1867 ?
17:22:47 <jlebon> that's not the same thing
17:23:04 <travier> Oh, ok
17:23:05 <jlebon> lua scriptlets have context that they rely on
17:23:31 <dustymabe> ok so the way I see it is:
17:23:40 <dustymabe> 1. to implement Lua we need something from librpm
17:23:51 <dustymabe> 2. librpm isn't willing to provide that
17:23:59 <dustymabe> 3. we must ask for a policy change to Fedora as a result
17:24:12 <dustymabe> the policy change should stir the discussion and possibly librpm will come around
17:24:26 <lucab_> [x] doubt
17:24:26 <dustymabe> or maybe an alternative solution will be proposed that is better
17:24:46 <travier> Usually the Lua script are there for state management or things that don't apply to rpm-ostree based systems
17:24:57 <bgilbert> I see some discussion in the rpm-ostree ticket that there might be alternative (hackier) approaches?
17:25:14 <bgilbert> like synthesizing a package with just the lua script and handing it off to rpm
17:25:50 <travier> So I think we ask for Lua scriptlet to only do things that can not be done via Bash or that are only for state management that do not apply to rpm-ostree.
17:26:11 <travier> we should*
17:26:19 <dustymabe> travier: that still sounds like a policy change?
17:26:22 <travier> yes
17:26:42 <jlebon> bgilbert: not sure how foolproof that is though. we'd need to dig more into what exactly is the context they run in, and how it'd differ if it actually ran in a separate RPM
17:27:21 <bgilbert> right
17:27:34 * dustymabe guesses we could fork librpm :(
17:27:57 <dustymabe> anybody with strong opiniions about how we should proceed
17:28:01 <dustymabe> that isn't the status quo
17:28:15 <lucab_> jlebon: silly though, could we detect the lua case in rpm-ostree and re-route those specific cases to a dedicated sandboxed transaction on its own?
17:28:51 <dustymabe> sorry travier, I ate OD
17:29:23 <jlebon> lucab_: it's worth investigating
17:29:40 <travier> alright, let's quickly move to OD
17:29:48 <travier> #topic Open Floor
17:30:10 <travier> (Will end in 5 minutes)
17:30:37 <lucab_> jlebon: ah, I see Colin already proposed a similarly crazy idea https://github.com/coreos/rpm-ostree/issues/749#issuecomment-644751946
17:30:40 <dustymabe> #info we're going to try to ship some ad-hoc releases on the `testing`/`next` stream with some updates for CVEs
17:31:03 <dustymabe> #info - next week's community meeting will be a video meeting (first meeting of the month)
17:31:22 <dustymabe> we'll discuss the f36 accepted changes
17:31:35 <dustymabe> travier: regarding the podman v4 discussion, where did we land on that
17:31:45 <dustymabe> do we need to try to re-engage with the podman team on that?
17:32:09 <travier> I answered in the thread here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4JRMF5IWBYZIOWG2UB2YVGXBWAQ36NMZ/
17:32:15 <travier> I have no answer so far
17:32:52 <dustymabe> You might have to point them at the list - not sure how much they read fedora devel (I admit I fail a lot of times to read it)
17:33:15 <travier> I pointed internally where I asked the question initially
17:33:33 <travier> and on the initial issue in FCOS
17:34:03 <dustymabe> so let's game this out a bit.. if they don't make any changes to their plans - what do we do? we already said we would ship it in `next`
17:34:17 <travier> https://github.com/coreos/fedora-coreos-tracker/issues/1070
17:34:47 <travier> Well, we kind of need packages to come from somewhere...
17:35:10 <dustymabe> i mean they are going to provide a package to us with podman v4
17:35:27 <dustymabe> but they didn't agree upfront to make it co-installable or anything
17:35:39 <dustymabe> the idea was just they'd build it and we'd ship it in next IIUC
17:35:43 <bgilbert> if we could figure out a path to helping them override the RPM within their constraints, that would give more options wrt the part they care about (podman-machine)
17:36:06 <dustymabe> that was discussed as an option, but we didn't agree to that last week
17:36:19 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/1070#issuecomment-1016700798
17:36:30 <bgilbert> right, we said we'd pursue it, timeframe unspecified
17:36:37 <travier> We suggested a lot of things and we received minimal feedback
17:37:21 <dustymabe> i think the feedback on the "override" approach is that it causes a long period of delay on startup in which the user has no indication of progress
17:37:35 <bgilbert> I don't think they care about running in next per se, so if we're having second thoughts about that...
17:37:35 <travier> We agreed to ship v4 in next. Not to remove v3, etc.
17:37:38 <bgilbert> dustymabe: right, that's the hurdle
17:38:05 <dustymabe> travier: hmm, I feel like that was implied considering they can't both be installed at the same time
17:38:23 <travier> We agreed to make podman v4 in next, not to not do the work to ship both too
17:38:25 <travier> *
17:38:25 <nemric> d'ho I'm so late !
17:39:05 <travier> I would really like to get an answer to that question: nothing points out that we can't install both at the time
17:39:09 <jlebon> i think the delayed start concern could be addressed
17:39:11 <travier> and choose on first boot
17:39:19 <dustymabe> jlebon: in what way?
17:39:20 <lucab_> speaking of v4, from the release notes it also contains data/state migration, so once in it is not safe to rollback
17:40:25 <dustymabe> lucab_: yeah I think that is right
17:40:42 <jlebon> dustymabe: `rpm-ostree install --cache-only $URLS_TO_RPMS -a`. this short-circuits metadata fetching and applies it live
17:40:59 <dustymabe> ok, to be clear when we did the vote last week, I don't think it was implied that they would need to do the work to make podman v3 and v4 co-installable
17:41:16 <bgilbert> dustymabe: agreed
17:41:25 <dustymabe> jlebon: it would be an override, not an install, correct?
17:41:34 <jlebon> dustymabe: ahh right, but same idea :)
17:41:37 <travier> No, but it did not imply that this would not be a good option
17:41:38 <jlebon> override supports cache-only too
17:42:02 <jlebon> it doesn't support -A, but it's equivalent to calling `rpm-ostree ex apply-live` afterwards
17:42:41 <jlebon> the heavyweight part is fetching metadata and libsolv processing it, which we'd skip
17:42:56 <travier> (We are well over)
17:43:01 <bgilbert> AIUI, we can satisfy their immediate needs by giving them a one-off OS build so they can meet their schedule, followed by a fast override command
17:43:04 <dustymabe> I guess we need to carry this into more discussions with ourselves and the podman team
17:43:18 <bgilbert> and then can navigate the FCOS migration to v4 as we wish
17:43:49 <jlebon> if they don't even want to wait for rpm-ostree to create a deployment, they could even `rpm-ostree usroverlay && rpm -Uvh $RPM_URLS` and then in the background run `rpm-ostree override replace`
17:44:07 <travier> Note than any override option that we choose will have to be CI tested too
17:44:20 <travier> And won't work offline
17:44:57 <travier> or in a private network setup
17:45:17 <jlebon> hmm, how do they fetch the FCOS image? or is there a knob to provide your own local image?
17:45:20 <travier> which again points us at shipping both in the image
17:45:41 <bgilbert> ...we could ship the RPM in the image :-(
17:46:10 <travier> https://docs.podman.io/en/latest/markdown/podman-machine-init.1.html
17:46:23 <dustymabe> i understand wanting to be conservative, but shipping just v4 seems like an OK option to me in `next`
17:46:30 <dustymabe> i guess I've stated that in the ticket already
17:46:32 <jlebon> travier: ack, thanks
17:46:54 <dustymabe> assuming it passes our CI
17:47:54 <jlebon> i don't think it's right to go back on what we decided last week. so short-term I think we should add it to next
17:48:01 <dustymabe> end meeting, pick up discussion in a more focused gathering tomorrow?
17:48:03 <lucab_> the elephant in the room is that people will have some podman (v3 or v4) installed from brew, and if the daemon does not support both then some breakage is going happen by design
17:48:16 <bgilbert> lucab_: +1
17:48:44 <travier> It's not going back from what we decided last week to ship both
17:48:51 <travier> back on*
17:49:04 <travier> Ending at :50
17:49:09 <bgilbert> jlebon: I think it's okay to revisit now that we've had more time to understand the implications, as long as we give them _some_ solution meeting their needs
17:49:11 <travier> in a minute
17:49:12 <dustymabe> travier: yes that is correct, but we'd have to do work to make shipping both possible
17:49:19 <dustymabe> and we can't make them do that
17:49:25 <jlebon> travier: that requires more work from them than was implied when that decision took place
17:49:26 <bgilbert> we also have a responsibility to our userbase
17:49:45 <jlebon> i don't disagree we should keep exploring options
17:49:55 <travier> I don't really understand how that could that much work to copy paste a spec file and tweak som filenames
17:50:20 <travier> #endmeeting