On Tue, Dec 13, 2011 at 08:30, Noah Watkins <jayhawk@xxxxxxxxxxx> wrote: > The debhelper tool and friends seem to do a good job of packaging up the > Java in this way, but integrating this into Ceph's default Debian scripts > means that anyone would now need a JDK to build Ceph with > dpkg-buildpackages. > > Is there a way to parametrize the Debian build process so people who don't > care about Java bindings can proceed? An alternative approach is to say have > another set of Debian build scripts in src/client/java/debian. The only parametrization I'm aware of is DEB_BUILD_OPTIONS, and it's not really meant to be used for toggling off bits of functionality. And if we would support DEB_BUILD_OPTIONS=nojava, would that mean not listing the java sdk in Build-Dependencies? That sounds like a bad road to take. The clean options I see are: 1. require anyone building the debs to have the java sdk debs installed 2. split the java bindings into a separate source package Frankly, I think 2. is decent option. Make ceph provide libcephfs-dev etc, make that a build-dependency of the java bindings. It complicates "build everything" but simplifies the common case. It lets these things evolve at different rates. It acts as a good check on whether we did a good job on libcephfs-dev packaging and API/ABI changes. I personally dislike it a lot when some upstream project tries to maintain all the language bindings in the world in the single master repository. That leads to a "one size fits nobody" world. For example, even our python bindings are *miserably* maintained compared to most true-Python projects; for example, they are not PyPI/pip-friendly. The reason why I've been ok with the python bindings is we use them internally, for tests etc, and I want to push more in that direction.. but we already have the PHP bindings in a separate repo. We don't need all the worlds bindings in ceph.git. -- 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
