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. 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 -- 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
