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. 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... cheers, Colin -- 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
