On Fri, Aug 26, 2016 at 4:24 PM, dani <dani@letai.org.il> wrote:



On 26/08//2016 21:18, Stephen John Smoogen wrote:
On 26 August 2016 at 12:58, Stephen John Smoogen <smooge@gmail.com> wrote:
On 26 August 2016 at 06:00, Daniel Letai <dani@letai.org.il> 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).