Re: rpm-ostree cliwrap effort
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 " 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: rpm-ostree cliwrap effort
On Fri, Jul 23, 2021 at 7:03 AM Colin Walters wrote: > > I was originally thinking of this as a Change, but since it won't be enabled > by default, and I think it's most useful to gather feedback from this group > first: > > See https://coreos.github.io/rpm-ostree/cliwrap/ > This is available since > https://github.com/coreos/rpm-ostree/releases/tag/v2021.6 > > But just for convenience of not following the link, run: > > $ rpm-ostree deploy --ex-cliwrap=true > (And `rpm-ostree ex apply-live` if you want) > > I'd like for some people interested in this (particularly ones doing > interactive CLI use, e.g. more "pet" systems like desktops) to try this out. > Is it useful for your muscle memory to have typing `yum|dnf update` just work > for example? If you forget you're in a host shell and not a container, is > the new error message from `dnf install` useful? > > Obviously the big change would be flipping this on by default - that'd be the > Fedora Change. > 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 " should overlay RPMs on the system, "dnf|yum upgrade" should do the rebase, etc. 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. 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. > Longer term though, part of the idea here is that I hope by thinking about > rpm-ostree as "image based dnf" this way, it also helps drive increase > alignment between the two. For example, around things like: > https://github.com/rpm-software-management/libdnf/pull/1204#issuecomment-884225903 > > If you have feedback, here is fine, or in > https://github.com/coreos/rpm-ostree/issues/2883 > 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. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
rpm-ostree cliwrap effort
I was originally thinking of this as a Change, but since it won't be enabled by default, and I think it's most useful to gather feedback from this group first: See https://coreos.github.io/rpm-ostree/cliwrap/ This is available since https://github.com/coreos/rpm-ostree/releases/tag/v2021.6 But just for convenience of not following the link, run: $ rpm-ostree deploy --ex-cliwrap=true (And `rpm-ostree ex apply-live` if you want) I'd like for some people interested in this (particularly ones doing interactive CLI use, e.g. more "pet" systems like desktops) to try this out. Is it useful for your muscle memory to have typing `yum|dnf update` just work for example? If you forget you're in a host shell and not a container, is the new error message from `dnf install` useful? Obviously the big change would be flipping this on by default - that'd be the Fedora Change. Longer term though, part of the idea here is that I hope by thinking about rpm-ostree as "image based dnf" this way, it also helps drive increase alignment between the two. For example, around things like: https://github.com/rpm-software-management/libdnf/pull/1204#issuecomment-884225903 If you have feedback, here is fine, or in https://github.com/coreos/rpm-ostree/issues/2883 Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
