On Mon, Nov 21, 2022, at 10:20 AM, Jonathan Lebon wrote: > On Tue, Oct 25, 2022 at 12:43 PM Colin Walters <walters@xxxxxxxxxx> wrote: >> - This proposal is explicitly trying to tie everything together. I think without the "bigger picture", it's actually *more* confusing. For example, just pushing the container images does little unless we invest in them as a derivation source and build tooling and docs around them. > > I agree it's helpful to discuss this at a higher level than the > individual pieces to make sense of it. But the proposal as is seems to > imply it will all be done in one cycle which I agree with Dusty is > very optimistic. I agree. > WDYT about introducing phases into the proposal? E.g. something like: > - phase 1 (f38): start pushing OSTree-based variants as container > images in Quay.io; users can opt into rebasing onto them > > - phase 2 (f39): automatically transition existing users to shipping > from Quay.io; users can opt out. > - phase 3 (f40): stop pushing OSTree repo updates entirely I'd agree that "stop pushing ostree repo updates" probably isn't going to happen in Fedora 38. Dunno, I guess we could try a f40 change that calls that out explicitly. > Some concerns about this have been raised upstream already around > whether hijacking the `dnf` command in that way could cause more > confusion than it's worth. ISTM like a cleaner approach would be to > build this out into `dnf` directly instead and have it drive > rpm-ostree. I agree with this longer term, though there's a *lot* of details here. We have the same problem with this that exists with dnf5 in that there are a *ton* of options that dnf exposes that we're unlikely to make work anytime soon. (A random example here is "-4 resolve to IPv4 addresses only" which seems tricky to plumb through the stack, particularly scoping in the container side). > It would be great to get feedback from the DNF maintainers about this > proposal and some of the ideas here. Agreed! I pinged them directly again but was hoping they'd see this Change and reply here. > I think this probably makes sense generally, but I'll note that for > Fedora CoreOS at least, the whole point is to have users' workloads > run in containers and decoupled from the host. E.g. we've gone to > great lengths to keep Python out for that reason (also, `cowsay` pulls > in Perl BTW :) ). Having non-finger compatibility with `dnf install -y > cowsay` was kind of a feature in that sense; it made users think twice > before falling into the same patterns as other systems. Now with this > and especially container layering, it gives more power to users but > weakens that messaging. This is true. But weakening that messaging (and making the technology more flexible) also *weakens the barriers* we've set up between "CoreOS" and other editions. (This topic gets confusing because we could be talking about the *build* side or the client side or both; I hope most people agree the CLI compatibility on the build side just makes sense) BTW I wanted to give an update here specifically regarding the "dnf image" bit - as of late, I've been working on a fresh new "bootc" CLI, see https://github.com/ostreedev/ostree-rs-ext/pull/412 and https://github.com/cgwalters/bootc and that may make more sense for the client side. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
