On Fri, Jul 23, 2021 at 7:03 AM Colin Walters <walters@xxxxxxxxxx> 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 <foo>" 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@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
