> The OpenSSL transition is keeping both versions around for a while, shunting the older version from package `openssl` to `openssl-1.0`, which will eventually

> The OpenSSL transition is keeping both versions around for a while, shunting the older version from package `openssl` to `openssl-1.0`, which will eventually go away too. In my experience, this hasn't been a terribly unsettling transition and has gone quite smoothly except for a few individuals unlucky enough to update during a mirror turnover (or so I gathered from the forums as their problems often went away after updating again a short time later). Mostly, insofar as OpenSSL 1.1.x is concerned vs. openssl-1.0, I've only had problems with projects that make heavy use of cmake as there's no easy workaround outside either a) creating/linking a few directories that cmake expects to find OpenSSL 1.0 in, or b) (my preferred approach because it avoids polluting the file system) patching the FindOpenSSL macro. But, I don't think this is a problem Arch needs to resolve as this is most certainly an upstream issue and only affects AUR packages (which, as you said, users of the AUR should already have some experience in this area anyway!). You're absolutely spot on with that last statement--one of the reasons I love Arch is because package maintainers keep things as close to upstream as possible and GCC updates have largely been painless. Certainly more so than I recall under Gentoo. Now that I think about it, the few pain points I've encountered with less frequently updated Arch installations have almost always involved multiple incompatible changes to core/filesystem layered with pacman updates. There are others, sure, but those ones seem to stick out in my mind the most. It's better to avoid them entirely by updating regularly, of course, but it happens.