Now you are proposing the same ( devtoolset/scl installs to /opt except for the wrapper call) but using a scheme that is somewhat less convenient (In scl the binutils and gcc have to be coupled, and as noted the imported gcc suite is incomplete), much less frequent (the most updated version is gcc-5.2, while I maintain both gcc-5.x and gcc-6.1), and much less complete (I import everything but gcc-gnat, while devtoolset4 only has gcc,gcc-c++ and gcc-gfortran. No gcc-objc, no gcc-go, no cpp, and none of the libs (cilk, gccjit, atomic, asan etc...).
I'm still building and maintaining both gcc and bintutils for my own purposes, which are based off of fc24 srpms, and with optionally gcc-c++ specs file hardcoded to use binutils tools at the new prefix so use of env-modules is not required.
I'm just wandering why the different treatment - the automatic knee-jerk reaction of dismissal to a newbie proposal vs. accepting the exact same proposal (although wrapped so it's less convenient to use) when it comes from someone else.
On 25/08//2016 06:59, Dave Johansen wrote:
On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi <kevin@xxxxxxxxx <mailto:kevin@xxxxxxxxx>> wrote:On Wed, 24 Aug 2016 16:43:31 -0600 Dave Johansen <davejohansen@xxxxxxxxx <mailto:davejohansen@xxxxxxxxx>> wrote: > On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi <kevin@xxxxxxxxx <mailto:kevin@xxxxxxxxx>> wrote: > > > On Tue, 23 Aug 2016 14:21:24 +0100 > > Karanbir Singh <mail-lists@xxxxxxxxx <mailto:mail-lists@xxxxxxxxx>> wrote: > > > > > On 22/08/16 18:30, Jason L Tibbitts III wrote: > > > >>>>>> "DJ" == Dave Johansen <davejohansen@xxxxxxxxx <mailto:davejohansen@xxxxxxxxx>> writes: > > > > > > > > DJ> devtoolset is designed to do all of this and is already > > > > DJ> done, so it seems that the only advantage to putting it in > > > > DJ> EPEL itself would be to reduce the number of repos during > > > > DJ> build time. > > > > > > > > So is devtoolset something I get access to as a CentOS user? > > > > How do I build these packages myself (i.e. in mock)? > > > > > > you should be able to 'yum install centos-release-scl' on a CentOS > > > Linux machine and get access to all the SCLs > > > > Yeah, but if we enable that for EPEL builds, we are going to get all > > SCLs right? So, people could start depending on them at runtime > > instead of just install time. > > > > I'm not opposed to devtoolset, but I don't think we want to allow > > runtime scls without actual scl guidelines. > > > > I seem to remember that Fedora didn't allow SCLs because there was > some compatibility problem or something of the sort. Do you know the > details or what the current state is? It's not a compatibility problem. It's lack of guidelines. > Also, RedHat has been pushing devtoolset pretty hard. The response to > a few bugzillas has even been "use devtoolset because the issue is > fixed there and we're not going to fix the system gcc/libc/etc". So > it seems like allowing SCLs in Fedora/EPEL makes sense and fits with > the direction of RHEL in general. As I noted, I'd probibly be for devtoolset because the guidelines would be pretty simple. Just do X Y and Z in your spec, build as normal and users wouldn't see any run time dep on it. It gets weird where other SCL's come in. Can your package require say postgresql from SCL instead of the rhel one? If so, would our users all be able to install that? What happens if two packages need different SCL versions? Can SCL's depend on each other? Can you make a package thats an SCL? we have no guidelines for that, and just saying "do whatever you want" is likely to cause mass confusion and make everyone miserable.I agree that how to handle SCLs can get really mess really fast, but a lot of projects are jumping on the "modern C++" bandwagon and allows devtoolset is low risk, easy to do and enables a lot of packages to be built with EPEL that otherwise wouldn't be.Basically, I think that figuring out how to handle SCLs is a long term issue that will take some serious work, but coming up with some simple policies that allow it to be used in EPEL is something that should be well within the realm of the possible._______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
