On Tue, Aug 22, 2017 at 1:01 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: > my main concern would be the downstream. how shall we accommodate the > packaging of downstream? for example, what if the boost package > maintainers of SuSE/fedora/debian/ubuntu are not ready to package the > boost version we want to use in future? Fedora has Boost 1.63.0 for a while, and f27 and f28 will have 1.64 or newer. I think we'll be ok there, because Jonathan Wakely tends to keep that very up-to-date. This is just brainstorming, I have nothing concrete here: For the CentOS side, and for the RH Ceph Storage downstream layered product, I am thinking about building an entirely separate boost RPM and just let it override the system version that ships in RHEL 7. I've tested rebuilding boost-1.64.0-0.8.fc28.src.rpm on RHEL in mock and it worked. (I had to remove the fiber, numpy, and python3 pieces). For Debian and older Ubuntu LTSs, we could do something similar: rebuild the boost source package from unstable/artful and let those override the OS versions. > actually almost all ceph_test_* are linking against libceph-common. > but they are linking against libglobal and libos statically. Is that the root issue with the debuginfo size? - Ken -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
