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. > But you're certainly not wrong, it *is* a big proposal. Happy to make changes, I'm mainly just saying there already are dedicated sub-proposal trackers to discuss the details of those. 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 This is just an example, we can break it down some other way. Also, it'd make sense to have the transition for each variant be driven by that variant's working group (obviously with collaboration between them). On that topic, it doesn't seem like we got any feedback from Fedora IoT at least. Also not sure where we stand for Fedora Silverblue and Kinoite. On Thu, Oct 13, 2022 at 3:09 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > * `rpm-ostree` is reworked to gain strong CLI compatibility with > `yum/dnf` commands (cliwrap) > * The new container native functionality is exposed via `dnf image` > * (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else) 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. Then the relationship becomes much clearer, and there's an obvious path towards gaining parity. Conveniently with dnf5 ditching Python, this becomes more achievable for systems that don't want Python. Things like `install` and `update` can more or less be passthrough as is (some debate there about whether to provide "advice" on whether what you're trying to install should be in a container instead; more of that below). Things like `status` would be valid in "image-mode" only to start, but then we could build out a traditional version of it. It would be great to get feedback from the DNF maintainers about this proposal and some of the ideas here. On Tue, Nov 1, 2022 at 9:34 AM Colin Walters <walters@xxxxxxxxxx> wrote: > I personally think "we'll actually just do what you asked for when you type dnf -y install cowsay" is a notable leap 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. I'm not sure if it's worth adding some artificial technological constraints to try to steer them back or just keeping it as a documentation thing would suffice. _______________________________________________ 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
