On Fri, Aug 26, 2016 at 4:24 PM, dani <[email protected]> wrote: > > > On 26/08//2016 21:18, Stephen John Smoogen wrote: > > On 26 August 2016 at 12:58, Stephen John Smoogen <[email protected]> > <[email protected]> wrote: > > On 26 August 2016 at 06:00, Daniel Letai <[email protected]> > <[email protected]> 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/fhs/ch03s13.html > > We would need to use the /opt/fedora or go through the process of > becoming an entity that the LANANA.org people would recognize. > > 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/... > 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 [email protected] https://lists.fedoraproject.org/admin/lists/[email protected]
