WIP/RFE: Hint to users to use ostree/rpm-ostree if we get EROFS

[cgwalters]

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.

[cgwalters]

This PR rolls in #319

After:

# rpm -e atomic
error: This system is managed by rpm-ostree
error: can't create transaction lock on /var/lib/rpm/.rpm.lock (Read-only file system)

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)

[herrold]

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

[cgwalters]

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.

[cgwalters]

BTW, down the line I'd like to extend this ostree-detection functionality a bit more so that e.g. rpm -V understands that timestamps are different, and that's OK.

[Conan-Kudo]

@cgwalters: This patch looks very specific to RPM-OSTree. Is there not a better, more general way to do this?

[cgwalters]

@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 but doesn't anymore 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.

[pmatilai]

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.

[cgwalters]

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