On Wed, Jun 24, 2020 at 09:22:39AM +0200, Petr Pisar wrote:
On Wed, Jun 24, 2020 at 06:51:36AM +0000, Zbigniew Jędrzejewski-Szmek
> I think there's some fear that "name mangling" is not a general
> solution, and we'd have cases where names conflict. I think the
> concern is realistic, but not a big issue in practice. With some
> careful naming guidelines we are able to resolve naming conflicts, and
> I'm sure we could extend the guidelines to multiple versions of language
> stacks or whatever. We'd probably have slightly longer names or packages,
> but that's not the end of the world.
Namespacing RPM package names is only a tip of the iceberg. You need to
namespace RPM requires, provides, shared library sonames, shared library
symbols, header files, header file symbols, pkg-config files, manual pages,
cross references in the manual pages, executable names etc. You need to
namespace everything if you aim for a parallel installability. That's the
reason why modularity does not tackle it and instead conflicts the concurent
versions by filtering the packages from the concurent streams.
I am very much aware that making things parallel-installable is an
order-of-magnitude harder than just parallalel-available. P-I is certainly
not going to come for free and would require some careful packaging. But
determined packagers can (and do) make it work. Also, some cases could be
easier, for example different minor versions of python (e.g. 3.x and 3.y).
Another example is P-I of different so-versions of libraries: Debian
has been doing this at scale since forever, so it's clearly not that hard.
The point I was trying to make is that we need a solution that works for
the easy case (P-A), but can allow handling the hard case (P-I) too with