Jeff Johnson wrote:
But create your own virtuality reality approach if you want.
I think you missed my point, which is that RPM packaging doesn't provide facilities for what needs to be done. Postgres upstream is just more honest than most in recognizing the problem. It's not the only thing that ever has non-backward-compatible updates.
I believe that one can easily conclude RPM packaging doesn't provide facilities for what needs to be done from Don't attempt postgres database upgrades in packaging.
You the one who wishes I'd just like to see a realistic approach to updates via packages.
Meaning I'd like RPM to be changed so multiple versions of packages could co-exist, as is often necessary in practice.
That Does Not Compute with current RPM facilities and existing postgres upgrade mechanisms.
Agreed, it doesn't work. Nor does any other RPM-managed update where you need to have both old and new packages simultaneously working for a while. The special case for the kernel is about the only place where it even attempts to keep old versions around for an emergency fallback.