On Thu, Aug 25, 2016 at 2:34 PM, Kevin Fenzi <[email protected]> wrote:
> On Wed, 24 Aug 2016 21:59:55 -0600 > Dave Johansen <[email protected]> wrote: > > > 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. > > It would be low risk if that was the only SCL in the repo. > My understanding is that they are all there in the one repo, so if we > enable that, everyone could start using anything thats in there. > They're each in their own repo and I would propose adding devtoolset only in repos used by mock during build time. On Thu, Aug 25, 2016 at 2:40 PM, Kevin Fenzi <[email protected]> wrote: > On Thu, 25 Aug 2016 12:52:46 -0400 > Stephen John Smoogen <[email protected]> wrote: > > > On 25 August 2016 at 02:14, dani <[email protected]> wrote: > > > When I proposed importing gcc-5 to EPEL6 back in 04/2016 ( > > > https://lists.fedoraproject.org/archives/list/epel-devel@ > lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/ > > > ) the response was an unequivocal no, EPEL does not install > > > to /opt/ , so it dies right there. > > > > > > 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. > > > > > > > You are misreading both responses. There is no knee-jerk acceptance > > and there wasn't a knee jerk dismissal because you were a newbie. > > Please don't find malice where none was intended. > > What smooge said. ;) > > The reason SCL's are under opt is that they got a namespace approved > for that purpose: > > https://fedoraproject.org/wiki/Packaging:Guidelines# > Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt > > "Currently, we have allocated /opt/fedora/scls, /etc/opt/fedora/scls, > and /var/opt/fedora/scls for use by Software Collections. " > > 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 think we are all open to ideas how to do things better, but it's > really not clear what is best or even exactly what is proposed. ;) Here's one proposal: 1) Add version X of devtoolset only in repos used by mock 2) N months (maybe 6?) before version X is EOLed, make version X+1 (or whatever the latest is) available in a buildroot override (or something similar) for testing 3) Rebuild all packages that use devtoolset using version X+1 and make available for testing 4) After testing period (maybe 1 month? or 3 months?), upgrade to version X+1 and move all rebuilt packages from testing repos to main repos Or here's another option: 1) Add all non-EOLed versions of devtoolset only in repos used by mock 2) N months (at least 6) before version X is EOLed require that it be rebuilt with a newer version of devtoolset 3) If it's not rebuilt before the EOL happens, then retire the package I like the second option better, because it's easier to setup/maintain from a mock/koji perspective, provides flexibility and doesn't force a mass rebuild/test every 12-18 months when a devtoolset is retired (their life cycle is 2 years). However, it also means that the update is decentralized and depends on maintainers rather an an automated system.
_______________________________________________ epel-devel mailing list [email protected] https://lists.fedoraproject.org/admin/lists/[email protected]
