From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brad Hubbard Subject: Re: increasingly large packages and longer build times Date: Thu, 31 Aug 2017 09:00:21 +1000 Message-ID: References: <71c7b782-6d7e-1e06-e889-bbbf9004ebfe@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from mail-lf0-f43.google.com ([209.85.215.43]:35123 "EHLO mail-lf0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbdH3XAX (ORCPT ); Wed, 30 Aug 2017 19:00:23 -0400 Received: by mail-lf0-f43.google.com with SMTP id g18so10433292lfl.2 for ; Wed, 30 Aug 2017 16:00:22 -0700 (PDT) In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Ken Dreyer Cc: John Spray , Sage Weil , Alfredo Deza , kefu chai , Nathan Cutler , Gregory Farnum , ceph-devel On Thu, Aug 31, 2017 at 8:07 AM, Ken Dreyer wrote: > On Wed, Aug 30, 2017 at 11:53 AM, John Spray wrote: >> 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. > > That scenario is theoretically possible, and it's good that you bring > it up for consideration. I'm trying to understand the likelihood of > the effort/disruption there. Do you have specific applications in mind > that would benefit in the way you describe? Ones that require boost > and are often co-installed on Ceph nodes? Any solution would need to protect against this. -- Cheers, Brad