On Thu, Aug 25, 2016 at 2:34 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Wed, 24 Aug 2016 21:59:55 -0600
Dave Johansen <davejohansen(a)gmail.com> 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 <kevin(a)scrye.com> wrote:
On Thu, 25 Aug 2016 12:52:46 -0400
Stephen John Smoogen <smooge(a)gmail.com> wrote:
> On 25 August 2016 at 02:14, dani <dani(a)letai.org.il> wrote:
> > When I proposed importing gcc-5 to EPEL6 back in 04/2016 (
> > https://lists.fedoraproject.org/archives/list/epel-devel@
> > ) 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:
"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
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.