On 27/08//2016 01:38, Neal Gompa wrote:They use alternatives which is wrong - it forces a default for the entire system, rather than on a per-user basis.On Fri, Aug 26, 2016 at 6:24 PM, dani <dani@xxxxxxxxxxxx> 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 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. 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.[2]: https://wiki.mageia.org/en/Libraries_policy 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 |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
