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. _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
