thanks to Adam for sharing a link to https://lindevs.com/install-gcc-on-ubuntu/ about Ubuntu's toolchain PPA according to install-deps.sh (https://github.com/ceph/ceph/blob/master/install-deps.sh#L318-L327), i see that Ceph used this in the past to get gcc9 in bionic, but it isn't currently enabled for focal. adding a call to "ensure_decent_gcc_on_ubuntu 11 focal" there should do the trick? that should be sufficient to start using c++20 on all of our branches On Fri, Feb 18, 2022 at 6:51 PM Matt Benjamin <mbenjami@xxxxxxxxxx> wrote: > > +1 > > On Fri, Feb 18, 2022 at 6:36 PM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > > > > Yeah, we’re not going to drop focal support for existing branches or for Quincy coming out in a couple months. Doing so for the R release *next year* is our historical pattern and what I’d support. > > -Greg > > > > On Fri, Feb 18, 2022 at 2:47 PM Anthony D'Atri <anthony.datri@xxxxxxxxx> wrote: > >> > >> > >> > >> >>>>> Don't forget we also need to keep building for older distros. I know > >> >>>> can we be more specific about this requirement? are you saying that > >> >>>> the R release still needs to build on ubuntu focal? or that our > >> >>>> octopus/pacific/quincy releases do? > >> >>> I was thinking we need to maintain support for Ubuntu 20.04 in our > >> >>> next release, yeah. But that may not be right; I guess we generally > >> >>> try and support the most recent LTS in our new branches. So maybe this > >> >>> is a non-issue? > >> > >> > >> >> okay thanks, i see what you mean. i think it would be ideal if we > >> >> could drop focal packages from all of our upstream releases. but if we > >> >> can't do that yet, we could continue building earlier releases in > >> >> focal so long as we avoid backporting any changes that require c++20. > >> >> i believe that's how we handled the switches to c++11 and 17 in the > >> >> past. though if we *can* drop focal entirely, that would make it a lot > >> >> easier to adopt the new c++20 features > >> > >> I’m a bit saddened by that idea. I do understand the desire to be free of older dependencies (Trusty got realllly old in that respect), and that adoption of container deployments (NOT looking to relitigate that) can help decouple the application from the underlying platform for those situations where it’s feasible. > >> > >> Many deployments, though, *can’t* update their OS (or Ceph for that matter) to the latest release in short order even if they want to. At fleet scale automation and monitoring is complex and must accommodate many other roles in addition to Ceph. Testing, qualifying, and iterating upgrades takes time, and it’s not unusual to have a year after an LTS for shakeout and to work in all the peices required — especially in cases where an in-situ upgrade isn’t feasible and the entire node gets re-imaged. > >> > >> Focal came out … less than two years ago. IMHO that’s an unreasonably short timeline for obsolescence, especially when Jammy isn’t due until late April — and enterprises are likely to wait for at least one dot release before deploying. Heck, there are lots of people who have only recently been able to roll out Bionic. > >> > >> Respectfully, sometimes we need to consider the lifecycle for existing clusters as well as for greenfield deployments. > >> > >> — aad > >> > >> _______________________________________________ > >> Dev mailing list -- dev@xxxxxxx > >> To unsubscribe send an email to dev-leave@xxxxxxx > > > > _______________________________________________ > > Dev mailing list -- dev@xxxxxxx > > To unsubscribe send an email to dev-leave@xxxxxxx > > > > -- > > Matt Benjamin > Red Hat, Inc. > 315 West Huron Street, Suite 140A > Ann Arbor, Michigan 48103 > > http://www.redhat.com/en/technologies/storage > > tel. 734-821-5101 > fax. 734-769-8938 > cel. 734-216-5309 > > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
