On Thu, 25 Aug 2016 15:04:58 -0600
Dave Johansen <davejohansen(a)gmail.com> wrote:
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.
Oh? thats good... I was understanding that they were all in a scl
repo/channel.
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.
Right. I would prefer the second one too, but we would still need some
automated detection that the packages no longer build.
kevin