Hi Colin, On Sat, Mar 19, 2011 at 01:29, Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote: > Hi all, > > ÂWe have made some progress recently on getting a Ceph RPM that works > on CentOS 5.5 and other Red Hat-derived distros. > > Now that our version number no longer includes a tilde, and the spec > file has been pruned a bit, I think we have a shot at building this > cleanly. > > I just have a few questions that perhaps people more experienced with > RPM packaging can answer: > > 1. should we have a debug SPEC file and a regular SPEC file? I think > in the long term we want to have both a Ceph and a Ceph-devel RPM > built. A single spec can produce multiple binary rpms, so this shouldn't be necessary. > > 2. What is the best way to bundle the python bindings? Currently I am > getting this error when building the RPM: >> error: Installed (but unpackaged) file(s) found: >> /usr/lib/python2.4/site-packages/rados.py >> /usr/lib/python2.4/site-packages/rados.pyc >> /usr/lib/python2.4/site-packages/rados.pyo > However, I need to find an RPM variable that has a path to the python > site-packages directory. automake knows this, but so far I haven't > figured out where this information lives in RPM. > > This guy suggests a workaround: > http://www.linux-archive.org/centos/171366-python-sybase-centos-5-x86_64-a.html > But his workaround seems kind of clumsy, and in fact doesn't work for > me on CentOS 5.5. Surely there is a standard way to refer to the > sit-packages directory in RPM without hacks? There are standard macros in recent versions of Fedora and RHEL6, but this should work: %if ! (0%{?fedora} > 12 || 0%{?rhel} > 5) %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} %endif If you add that to the top of your spec you can use %{python_sitearch} in your %files section. There are more tips at http://fedoraproject.org/wiki/Packaging:Python > 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.). Is google-perftool an EPEL package? If so can you report a bug against that package at bugzilla.redhat.com? An option would be to split out tcmalloc into it's own rpm. > And in general, how > do we handle things that are "good to have" but which shouldn't be > dependencies? Ah, that's one of the problems of RPM :) There's no such thing as Recommends or Suggests. Some people handle this by adding conditional macros to the spec file. This enables you to rebuild the source rpm by specifying rpmbuild --with python for example. The libvirt spec file is a good example of this: http://pkgs.fedoraproject.org/gitweb/?p=libvirt.git;a=blob;f=libvirt.spec > cheers, > Colin Kind regards, Ruben -- 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
