On Thu, Aug 31, 2017 at 3:53 AM, John Spray <jspray@xxxxxxxxxx> wrote: > On Wed, Aug 30, 2017 at 6:17 PM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: >> On Sun, Aug 27, 2017 at 4:30 PM, Brad Hubbard <bhubbard@xxxxxxxxxx> wrote: >>> Should we ship a ceph-boost, etc. package then that does not overwrite >>> distro packages (installs in a different location)? >> >> On the RPM side, ceph depends on the libboost_* sonames directly. So >> our ceph-boost package would need to provide those, and Yum may still >> prefer it over the standard system boost. >> >> What is the specific risk of overriding RHEL's and Ubuntu's system >> boost? (Are there some common packages that users typically install on >> ceph nodes that would also depend on the old system boost?) > > The thing is, our boost could easily end up being the "old" one, if > the distro is shipping security updates to theirs. Our > higher-numbered boost packages would potentially block the distro's > updates to their lower-numbered boost packages. If we ship our own > separate boost, then maybe Ceph is stuck with an un-patched boost, but > other applications on the system are not. > > It's not necessarily intolerable, but if the goal is packaging hygiene > then it's a bit self-defeating. I'm looking into this, as well as other options to reduce the size (hopefully). Open to any further ideas of course :) > > John > >> >> - 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 -- Cheers, Brad -- 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
