On 27/08//2016 01:38, Neal Gompa wrote:
On Fri, Aug 26, 2016 at 6:24 PM, dani <dani@letai.org.il> wrote:
I think it is high time to rethink the single version of a package policy,
and come up with some scheme that would allow for any package to maintain
multiple versions in a consistent manner.
We wouldn't even be the first distro to wind up discarding that
policy. Both openSUSE and Mandriva did the same many years ago. That
led to the restructuring of the packaging to the current form openSUSE
and Mageia have[1][2].

[1]: https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines
They use alternatives which is wrong - it forces a default for the entire system, rather than on a per-user basis.
See mpi-selector for a better approach - it allows both a system wide and a user default, the later taking precedence over the former.
It was deprecated in favor of environment modules, BTW.
[2]: https://wiki.mageia.org/en/Libraries_policy


This only handles major version numbers AFAICT, and devel packages with versions in the names are considered an exception, which in my opinion is not a good approach.

Under my scheme there can be multiple devel packages, each linked to it's "main" package by means of a standardized prefix.
I use e.g. gcc6.1.1-gcc gcc6.1.1-gcc-c++ etc. for the entire suite, so there are no name conflicts as well as no path conflicts, and makes it easy to install/remove an entire version by the use of yum install gcc6.1.1\*

This works for me, but I'm aware my use case is quite limited and might have drawbacks which make it unsuitable for epel.

I believe scl uses a postfix scheme which I personally find less convenient, but I could adopt that easily if required.

[1]: http://rpm.pbone.net/index.php3/stat/45/idpl/22601613/numer/1/nazwa/mpi-selector