On Fri, Aug 26, 2016 at 4:24 PM, dani <dani@xxxxxxxxxxxx> wrote:
I think /opt/fedora would be fine, but it would require an additional level to allow for better flexibility, something like /opt/fedora/epel[6?]/gcc/5.3/.
On 26/08//2016 21:18, Stephen John Smoogen wrote:
On 26 August 2016 at 12:58, Stephen John Smoogen <smooge@xxxxxxxxx> wrote:On 26 August 2016 at 06:00, Daniel Letai <dani@xxxxxxxxxxxx> wrote:On 08/25/2016 11:40 PM, Kevin Fenzi wrote: Perhaps you could explain exactly what you want to propose here again? Just epel6? or 7 as well? Do you have co-maintainers in case you get busy, etc? I propose adding several gnu packages (namely gcc, binutils and gdb) with versions following those supplied by fedora, specifically for epel6, but possibly for epel7 if requested. This could hold a pattern such as /opt/gnu/[gcc|binutils|gdb]/<version>/ to allow several version to co-exist. I don't have any co-maintainers, but I mainly get busy in my day job, which happens to be the reason I maintain those packages. OK there were multiple reasons there were reservations for this: 1) /opt/gnu (and many other /opt/*) names are already in use by many site admistrators. Putting our packages in there and over-writing locally compiled apps is going to cause problems. [Remember rpm will overwrite /opt/gnu/gcc/5.0/bin/gcc if it wasn't in the rpm db before hand without any report of a conflict.]In reading some of the FESCO tickets, we can't use /opt/gnu because we are not the GNU organization. https://refspecs.linuxfoundation.org/FHS_3.0/ We would need to use the /opt/fedora or go through the process of becoming an entity that the LANANA.org people would recognize.fhs/ch03s13.html ..
If possible, /opt/epel/gcc/... is more intuitive, but might require registration ( I'm not familiar with any other "epel" out there that might contest the use of "epel" as a new provider).
This would also allow for differing python version (/opt/epel/python/[2.7,3.0,3.4...]) or any other multi-version package some might wish to maintain.
I realize this is not the fedora way, to maintain multiple version of the same package, and over the years this had led to some inconsistencies in naming - python might be the most known example, but other packages exists which had to do with all sort of *-compat or name<numer> kludges.
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.
gcc is just a single example where such a need exists. Perl, python and any other tool that breaks api between versions is of course a candidate.
SCL, while apparently solving this issue, seem to break the modular approach to software delivery that is rpm - you have to use fixed versions provided by an scl suite for the entire tooling, rather than upgrading or using tools from different versions as long as they are compatible.
I believe that's just a design decision to make it easier to work with a compiler toolchain. devtoolset could probably be broken up into a few smaller chunks (compiler, IDE, debugging tools, etc), but I don't know if there's any significant benefit to completely separating each component so you can mix different versions (assuming that something like that is even possible).
_______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
