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