On Fri, Jul 23, 2021, at 7:20 AM, Neal Gompa wrote:
I think I'd prefer that if you intend to do CLI wrappers, that the
wrapper matches the semantics of the original tools as much as
possible.
That is, "dnf|yum install <foo>" should overlay RPMs on the system,
I can certainly see ultimately making this configurable (locally and per edition). Some
people definitely want "dnf with images and transactional updates", i.e. they
haven't adapted to a world living in containers. For example, these people might be
installing things like `gcc`, `mock` etc. to the host system. They might still have a web
browser lifecycle bound with the operating system. Whereas the current behavior is
obviously explicitly intended to push people into containers, because the benefits are
powerful (to them, and us).
So yes, we could have an option where `dnf|yum install` just silently runs `rpm-ostree
install -A` instead of printing the error it does today pretty easily. But then:
"dnf|yum upgrade" should do the rebase, etc.
Matching semantics exactly gets tricky because then - `dnf upgrade` equivalent to
`rpm-ostree upgrade && rpm-ostree ex apply-live` or is it just (as the code
supports today) `rpm-ostree upgrade` i.e. queued for next boot?
The thing is, ultimately I don't believe "online upgrades" should be the
default. I know this is a highly polarizing topic =) But basically it's just chock
full of race conditions except in a very few targeted cases. It can mostly appear to work
most of the time, but you can get spectacular failures too.
What I've concluded is basically offline updates are the default, but it should be as
easy as possible for the system administrator to "cherry pick" a subset of those
updates live. For the nightmare scenario of e.g. an openssh unauthenticated RCE, it
should be like `rpm-ostree apply-live openssh` that pulls the queued updated openssh that
would be on the next boot and applies it live, while leaving e.g. a queued not-security
kernel update (also because changing what `rpm -q kernel` says is also just always a
confusing lie).
However, if you *don't* intend to preserve semantics, then
don't
bother doing it *at all* because it'll just lead to confusion. Error
messages are not helpful.
We'll have to disagree there! I mean I've been doing this for years now and
constantly talking to people and e.g. the "engineer/tester trying to replace the
kernel with yum install" section in
https://github.com/coreos/rpm-ostree/issues/2883
is just one example of something I know this will help with.
It's just better to not have the command at
all in the first place in that circumstance. Imagine how much you'd
break scripts and automation by having something "pretend" to be
DNF/YUM without actually being able to *do* the things people expect
it to do.
Yep, a member of my team recently raised this concern and I agree it's a problem. I
filed
https://github.com/coreos/rpm-ostree/issues/3009
which I'll probably do pretty soon.
I'm not sure this is a useful way to position it, since
RPM-OSTree
works completely differently and classes of RPMs don't even work on
the system. Additionally, the emphasis on using OCI images, Flatpaks,
and other non-RPM content instead of native RPM content on these
systems means that "image based dnf" is disingenuous and a potential
source for confusion, since you've been pushing to *avoid* supporting
workflows people do on regular Fedora systems.
I think RPM isn't any more native than containers. It's just a tool, a technique;
not the axis around which everything revolves or should revolve.
Thanks for the feedback and discussion! I think people will have a variety of opinions
here and it's good to have those represented.