On Wed, Aug 23, 2017 at 10:53 PM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: > 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? not sure about this =(. i have not tried to root-cause the issue of debuginfo size yet. > > - Ken -- Regards Kefu Chai -- 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
