WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS#320
WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS#320cgwalters wants to merge 2 commits intorpm-software-management:masterfrom
Conversation
I was actually testing a change to better handle `rpm -e atomic` on Fedora Atomic Host, wondering why my patch was crashing, but in fact it was the recently added sync code in master.
Down the line, it's likely that for rpm-ostree based systems we'll install an interceptor for `/usr/bin/rpm` to redirect at least things like local package installs. There's a lot of work to do for that, so in the meantime let's help admins out by giving them a helpful error message.
|
This PR rolls in #319 After: This is still a WIP/RFE - the code here isn't pretty obviously, happy to have feedback about a better way to do it. (Also honestly I'm struggling to convince Emacs to do this mix of tabs/spaces in the rpm codebase) |
|
As I understand the model for rpm-ostree, it assumes a Read Only, and re-located RPMDB Wouldn't a more general fix than the one seemingly already committed about inability to calculate TS disk size requirements, be a simply attempt to connect with the BDB and get a lockfile? this would indicate reliably and early, that RW transactions as called were not going to happen, and once might exit early, and with more information to a admin |
|
Hi @herrold - I read your comment a few times and I'm confused...isn't that what my patch is doing? BTW, it's easy to try an rpm-ostree based system, see https://getfedora.org/atomic/ and https://pagure.io/workstation-ostree-config for example. One thing I'd note though is that the rpm database is read-only from the point of view of everything except rpm-ostree - we support both package layering and live package layering. But even when doing live changes, the system still appears read-only to everything else due to some underlying ostree magic. |
|
BTW, down the line I'd like to extend this ostree-detection functionality a bit more so that e.g. |
|
@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
Well, it's not an advertisement - we don't and will never support librpm doing (persistent¹) writes. This isn't like how So...a path we could pursue instead of this would be having ¹ |
|
NAK for polluting main rpm code with rpm-ostree specifics, and lockfile creation seems like the wrong place to do that anyhow. The place for this kind of material is an rpm plugin which some rpm-ostree component depends on it so its there when needed without bothering others. |
|
Just to xref, since this one was closed the current plan is for rpm-ostree to wrap rpm, instead of having rpm wrap rpm-ostree: coreos/rpm-ostree#1789 |
Down the line, it's likely that for rpm-ostree based systems we'll
install an interceptor for
/usr/bin/rpmto redirect at least thingslike local package installs. There's a lot of work to do for
that, so in the meantime let's help admins out by giving them a
helpful error message.