Add install --force-replacefiles

[jlebon]

Add support for RPMs which want to override files from other RPMs. This
could be useful generally, but specifically for example in OCP where
we're toying with bundling user-provided overrides as RPMs.

We're effectively surfacing rpm's --replacefiles switch, though in a
slightly safer way because while we do turn on the associated rpmdb flag
globally (RPMPROB_FILTER_REPLACEOLDFILES), we're only allowing the
checkouts of those specific packages to replace files.

This is also rendered separately in status as LocalForcedPackages.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cgwalters]

/test all

I think having a provides marker for this is OK, but it feels like it'd be too easy for some 3rd party rpm-md repo to add this and have something unexpected happen again like replacing libc.so.

I guess I'd lean more towards something like rpm-ostree install --force-replace ./kubelet.rpm or so - and on the DBus/origin side this would be an explicitly separate packages-force-replace or so?

[cgwalters]

(I know you know this, but I'm just re-linking here for completness for others to #2326 because it would make things exactly like this easier to implement and more obvious to users I think if we had a declarative format)

[cgwalters]

That said if you prefer this model I'm OK with it, just two other things:

• What if we at least suggested this to the rpm/dnf community? We've built up a lot of rpm-ostree "special sauce" and this would be another one. But it could make sense for rpm/dnf too right?
• Would be good to have tests + doc somewhere

[jlebon]

That said if you prefer this model I'm OK with it, just two other things:

I think having it be gated client-side makes sense. I was thinking at first the RPM itself should be marked somehow since it's a specialized payload (in the OCP use case). But higher-level, I think it's clearer to just generalize to "let's expose rpm's --replacefiles switch" (though slightly nicer because it'd be enabled per-RPM thanks to the ostree checkout and not just at the transaction level).

What if we at least suggested this to the rpm/dnf community? We've built up a lot of rpm-ostree "special sauce" and this would be another one. But it could make sense for rpm/dnf too right?

If we go that way, there wouldn't be any special rpm-ostree sauce. Though I noticed now that dnf/libdnf doesn't today expose a way to enable --replacefiles. I can file an RFE for that.

Would be good to have tests + doc somewhere

Yup, will do!

[jlebon]

Circling back to this, I was hacking on adding rpm-ostree install --replacefiles, but... hesitating a bit on having this be under install. Being able to replace base files is more akin to overrides, but I'm not sure how to nicely fit it into the overrides command. Maybe just rpm-ostree override replacefiles foo.rpm?

[jlebon]

No, I think putting it in install is still better overall UX-wise, and just making the switch scarier. I like --force-replace as suggested above, or maybe --force-replacefiles as a nod to the equivalent RPM option.

[jlebon]

Updated this now and added a test! As expected, it's way more churn because we need to store it separately in the origin. I debated making this just a special kind of LocalPackages, maybe extending the sha256:nevra string format to something like sha256:nevra[,flags] or something but meh... wasn't hard either to just copy/paste where needed, and didn't want to change formats just to make things temporarily easier if we're going to rework the origin stuff anyway.

Can split prep patches out if desired.

[cgwalters]

LGTM!

Just noting this is another case of needing a lot of "data plumbing" that would be less necessary with #2326

[cgwalters]

One thing I just wanted to add related to this; a way in which this is a very "rpm-ostree" feature is the way it's implemented it does not have hysteresis.

In other words, with traditional rpm, the fact one used --replacefiles doesn't persist - it's a point-in-time action that isn't recorded persistently.

But here, the fact that we're recording exactly which packages have this flag on in rpm-ostree status both makes the situation very clear and understandable, and allows reproducing it across upgrades.