|
On 26/08//2016 21:18, Stephen John
Smoogen 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 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/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. 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. |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
