On Thu, 25 Aug 2016 15:04:58 -0600 Dave Johansen <davejohansen@xxxxxxxxx> wrote: > On Thu, Aug 25, 2016 at 2:34 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > On Wed, 24 Aug 2016 21:59:55 -0600 > > Dave Johansen <davejohansen@xxxxxxxxx> 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
Attachment:
pgpEPQpRNhYls.pgp
Description: OpenPGP digital signature
_______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
