How should librmm's runtime version be constrained by packages that build against it?

[vyasr]

Currently librmm has a run_export on itself. This is not technically correct: since librmm is a header-only library, it actually is not necessary for librmm to exist at runtime for any package that built against librmm. However, it does serve a purpose. If two packages that use librmm are built against different, ABI-incompatible versions of librmm, and if they exchange librmm objects across interface boundaries, the interchange will fail. Therefore, indicating a run dependence on librmm is effectively like using it as a metapackage to constrain the runtime ABI requirements of all packages in an environment that use librmm.

That being the case, are we comfortable with always making librmm a runtime requirement of anything that builds against it, along with a suitably tight pinning?

I started thinking about this problem due to rapidsai/xgboost-feedstock#44, which I'm now also not convinced is really correct. If two packages built against librmm only included a run_constrained entry and ignored the run export, then you could install versions of those libraries built against completely different (and incompatible) versions of librmm and conda would happily do so because neither of them would actually install librmm at runtime. However, this probably needs to be balanced against the fact that some packages may only use librmm conditionally (i.e. they may enable GPU support conditionally) and therefore don't want to force installation of librmm. I'm not sure what the right answer is here, and I don't think there's a silver bullet, but it would be good to at least align on best policies here.