Hi Fabian, On Wed, 13 Jun 2018, Fabian Grünbichler wrote: > On Mon, Jun 04, 2018 at 06:39:08PM +0000, Sage Weil wrote: > > [adding ceph-maintainers] > > [and ceph-devel] > > > > > On Mon, 4 Jun 2018, Charles Alva wrote: > > > Hi Guys, > > > > > > When will the Ceph Mimic packages for Debian Stretch released? I could not > > > find the packages even after changing the sources.list. > > > > The problem is that we're now using c++17, which requires a newer gcc > > than stretch or jessie provide, and Debian does not provide backports of > > the newer gcc packages. We currently can't build the latest Ceph for > > those releases. > > IMHO this is backwards. if you want to support distro X you should take > care to not need toolchain features that are not included in distro X. Well, I thought we did. When we were making the C++17 decision we verified that we could do builds on Ubuntu and CentOS using a newer compiler toolchain. My assumption was that since both of these distros had backports that pretty much everyone did. Clearly I was wrong. > [...] > effectively this means the current Xenial builds are about as safe and > production-ready as doing your own gcc backports for Stretch - i.e., not > very. I missed this nuance as well. > > We'd love to build for stretch, but until there is a newer gcc for that > > distro it's not possible. We could build packages for 'testing', but I'm > > not sure if those will be usable on stretch. > > saying you'd love to build for a distro, while effectively making sure a > build according to that distro's release policies is impossible without > major effort by someone else does strike me as a bit of a hollow > statement. in the end this is a further nail in the coffin of upstream > support for the Debian(-based) distros, with only the latest (1.5 months > old!) Ubuntu LTS being properly supported. I think we need to be clear about the use of the term "support" here. I was careful to say we'd like to *build* for Debian, but I'm not sure what organizations out there are offering formal *support* for any of the ceph.com packages (in the sense of providing technical support for bug escalations or any guarantees around stability etc). This incident is perhaps an indication that those organizations should become more involved in the upstream development and decision-making process. > I hope we find some way to support Mimic+ for Stretch without requiring > a backport of gcc-7+, although it unfortunately seems unlikely at this > point. It is not practical to reverse the dependency on C++17. A lot of C++17 code has already made it into the tree, and the use of projects that require it (notably Seastar) is a *big* part of our plans going forward to improve performance on flash devices. Again, I would still like to provide these builds. If the requirement to do so is a high level of assurance that the backported compiler used is solid and the resulting builds have been tested, then that will take some additional effort--at a minimum, adding stretch to the set of OSes that we test in the sepia lab. This is probably not that much work, TBH, but does require someone who cares to become engaged in the testing effort. There are daily and weekly standups you can join, and of course discussions take place on IRC (#sepia) and over email (ceph-devel and ceph-maintainers). The immediate practical issue/question, IIRC, is simply for someone to verify whether a build using the debian testing version of gcc will produce a package that can be installed without additional dependencies on stretch. Or maybe this question was already answered and a backport is definitely needed. Regardless, it seems to me like the compiler version in testing would be an appropriate choice for a gcc backport to stretch. One final note: we didn't move to C++17 for no reason: we did so because it is difficult to move the Ceph project forward without taking advantage of the new language features. It took us a *long* time to get to C++11 because of paranoia around distro support, but we finally realized that we could move more quickly if we rely on the compiler backports available in most distros (tho clearly not as many as we thought!). I wish we had moved much sooner with C++11, and I still think this was the right decision with respect to C++17. I'm sorry that this has caused problems with Debian, but I think with your (or someone's) help we can mitigate the damage with testing. Thanks! sage