On Mon, Nov 21, 2022, at 10:20 AM, Jonathan Lebon wrote:
On Tue, Oct 25, 2022 at 12:43 PM Colin Walters
<walters(a)verbum.org> 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.