As for your 2) to deploy small clusters I think that is outside the scope of packaging. Take mysql for example. you could configure mysql to be master/slave or even master/master. That is all done through the configuration not through the package.
The hadoop configuration is very dependent on hostnames nn,jt,snn,(dn) disks mounted outside of root. So I don't think you should package up the logic to auto deploy a cluster of any size, if that was what you were implying. Edward On Thu, Jan 7, 2010 at 6:30 PM, Jordà Polo <[email protected]> wrote: > On Mon, Jan 04, 2010 at 12:37:48PM +0000, Steve Loughran wrote: >> If you want "official" as in can say "Apache Hadoop" on it, then it >> will need to be managed and released as an apache project. That >> means somewhere in ASF SVN. If you want to cut your own, please give >> it a different name to avoid problems later. > > I actually meant "official" as in "Debian official", that is, a package > that is compatible with the Debian policies and follows the standard > best practices, and thus is able to be included in the official Debian > distribution. (Note that I come from the Debian side where I maintain a > few packages. Sorry about the misunderstanding, I took that for > granted.) > >> Well, we'll just have to ignore the debian autobuilding process >> then, won't we? >> >> There are some hooks in Ivy and Ant to give local machine artifacts >> priority over other stuff, but it's not ideal. Let's just say there >> are differences in opinion between some of the linux packaging >> people and others as to what is the correct way to manage >> dependencies. I'm in the "everything is specified under SCM" camp; >> others are in the "build against what you find" world. > > Well, if you want an official Debian package, you can't really ignore > the autobuilding process, but that's not necessarily a problem. I mean, > you only need to take it into account when building the official > package, not your customized packages. > > So, for the initial versions of this "official Debian package" I was > thinking of the following use cases: 1) developers that need the > libraries and maybe even to test applications locally, 2) to deploy > small clusters, and 3) as a base _source_ package that can be customized > and rebuilt for larger environments. IMHO, an official Debian package > would be worth it even if it only provides 1 and 2. > >> >(Anyway, I'm interested in the package, so let me know if you need some >> >help and want to set up a group on alioth or something.) >> >> A lot of the fun here is not going to be setting up the package files ( > > Hmm, I'm not sure what you mean, but I'm don't think my sentence was > correctly understood either, so I'll try to put it into context: Debian > packages can be either maintained by a single maintainer or by a group > of them. Alioth[1] is a project-management service used mostly for > Debian-related projects (such as packages). An Alioth project could be > useful to create a mailing list and deal with Debian-specific bug > reports and packaging issues (which are off-topic here). > > 1. http://alioth.debian.org/ >
