[Rpm-maint] [rpm-software-management/rpm] WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS (#320)
notifications at github.com
Sat Sep 9 19:00:12 UTC 2017
> @cgwalters: This patch looks very specific to RPM-OSTree. Is there not a better, more general way to do this?
More general to...other image systems that happen to use rpm? Possibly. As far as I'm aware though rpm-ostree is fairly unique in the way it's a hybrid image/package system. I guess the old oVirt Node "classic" model might apply, AFAIK they shipped rpm but had no unlock functionality even. (slapping an overlayfs on /usr is really handy!). But they switched to https://github.com/fabiand/imgbased with everything writable so `yum` works. (But `yum` is totally unaware of the underlying image system)
> if ostree permits live update even with -EROFS, then your patch should teach rpm to do similar live-update, not spew nagware adverts.
Well, it's not an advertisement - we don't and will never support librpm doing (persistent¹) writes. This isn't like how `dnf` (used to thankfully) print a message and continue for people who type `yum`. This case is a hard error.
So...a path we could pursue instead of this would be having `/usr/bin/rpm` be a symlink → `/usr/bin/rpm-ostree`. There's a lot of advantages to that, but it'd also be obviously a large maintenance overhead of detecting operations we want to intercept (basically writes like `-i`, `-U`, but not `-q`). If consensus favors that I'd be OK with doing that instead.
¹ `rpm -Uvh` etc work fine on top of `ostree admin unlock`, which is intentional and very handy (and in fact how I tested this patch, by building a new rpm of rpm and installing it that way). But the way persistent changes work is totally different.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-maint