On Mon, 21 Mar 2011, Colin McCabe wrote: > On Mon, Mar 21, 2011 at 9:09 AM, Tommi Virtanen > <tommi.virtanen@xxxxxxxxxxxxx> wrote: > > On Fri, Mar 18, 2011 at 05:29:51PM -0700, Colin McCabe wrote: > >> 3. How should we handle tcmalloc, if at all? Google-perftools is not > >> bundled for 64 bit on CentOS. (It seems like this decision was made > >> because some of the stuff in this package is buggy on 64 bit x86. > >> However, tcmalloc itself is not buggy on 64 bit.). And in general, how > >> do we handle things that are "good to have" but which shouldn't be > >> dependencies? > > > > Hmm. The whole point of commit a2c02d was that it'd be harder to > > accidentally build a non-desired variant of Ceph. That is, just > > because you reinstalled the machine you use for building the package, > > and forgot to install libatomic-ops-dev, doesn't mean you should > > create packages with completely different behavior in the future. > > > > So, you need to figure out whether libatomic-ops is desired or not, > > for the relevant platform/architecture. If yes, then builds must fail > > without it (./configure will complain, debs have build-dependency). If > > not, then say ./configure --without-libatomic-ops. But don't let it > > depend on unpredictable factors. > > I agree that libatomic-ops should be mandatory. > > The more annoying dependencies are things like GTK2, which don't > really affect the behavior of the rest of the project, but which will > have to be "mandatory" in the RPM, it seems. We should really break that into a separate package at some point. The main roadblock there iirc is breaking it into a separate binary. Originally I thought we should have it launched via the ceph tool (similar to the git subcommands) but at this point I don't really care either way. > Also, as I said, tcmalloc > will present somewhat of a problem because it's just not packaged on > RedHat/CentOS at the moment for 64-bit. I will report a bug with Red > Hat and see what they think... Yeah, getting it packaged would be ideal. Let's see how that goes. Maybe stick something in the wiki that people can modify the .spec to build without it in the meantime? sage -- 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
