SIGs/bigdata/packaging

If you're wondering what Big Data things are in Fedora, or are interested in working on packaging or reviews to help out the Big Data SIG, this is the page to look at!

If you know of a big-data-related package that is already in Fedora, or have one that you'd like to get into Fedora, be sure to list it here, or link to the page describing what needs to be done, or link to the bugzilla that needs help.

Packages available in Fedora

Project	Since	Description	Notes
HTCondor	F8	A scalable batch scheduling system
Apache ZooKeeper	F18	A service for highly reliable distributed coordination
Savanna	F20	An OpenStack project for managing Hadoop clusters and workflow
GlusterFS Hadoop	F20	An HCFS plugin for Gluster
Apache Hadoop	F20	Batch processing system and core of the Hadoop ecosystem	Hadoop F20 Change
Tachyon	F20	A memory resident, fault tolerant distributed file system	Tachyon packaging
Apache Mesos	F21	Cluster manager for sharing distributed application frameworks	Mesos packaging
Apache HBase	F21	The Apache Hadoop Database	HBase packaging
Apache Pig	F21	Language for expression data analysis programs run on MapReduce	Pig packaging
Apache Solr	F21	Ultra-fast Lucene-based Search Server	RHBZ #1025904
Apache Spark	F21	Lightning-fast cluster computing	Spark packaging and Scala packaging
Apache Hive	F21	Hadoop data warehouse	Hive packaging
Apache Ambari	F20,F21	Hadoop cluster manager	Ambari packaging

Packages in review

• the bigdata-review-tracker

Project	Review BZ	Who	Notes
Apache Oozie	RHBZ #1071456	rsquared	Oozie packaging
Apache Sqoop	RHBZ #1089675	pmackinn

Packages we're working on

Project	Who	Notes
Apache Mahout	besser82
Apache Accumulo	ctubbsii	In progress for F21

Packages we'd like to include

• Shark
• Mesos Frameworks
  • Aurora
• Sparrow
• Flume
• Storm
• Tez
• Presto
• Storm
• Cascading
• Summingbird
• RHadoop
• Sentry
• Ooyala Job Server
• unicage
• GridGain
• New stuff here!

Becoming a packager

Not yet a packager? Check out the Package Maintainers, or the Join the package collection maintainers page to get more information. You could also ask on the Big Data SIG mailing list for assistance and see if you can find a willing helper or sponsor. For bundling Java packages read the Java packaging guidelines first.

Typical workflow (relies on github)

• Clone original repo, if modifications are required.
• Patch where necessary. (Use github tickets where possible if working as a group).
  • Try to organize your patch set into meaningful units, and create tickets to push upstream where possible.
  • For patches that require carrying, they should be applied to the raw-sources where possible.
• Create a package-rpm repo with specs and system integration files (systemd, custom-conf, etc).
• Use rpmbuild | hack fedpkg to enable prototype package building
  • spectool -g package.spec (will download sources)
  • md5sum package-sources.tar.gz > sources
  • fedpkg local
• Once you feel you have a package ready for review run the following prior to submit:
  • Setup Fedora Review
  • rpmlint package.spec
  • mock --clean --init -r fedora-rawhide-x86_64 && fedora-review -m fedora-rawhide-x86_64 -n package.srpm

Packaging Notes

• Fedora java rpms can not bundle dependent jars. Every jar file not created by the build must come from an rpm in the Fedora repository.
• All jars must be built from source
• Fedora build tools: xmvn-resolve, mvn-local, mvn-rpmbuild, mvn-build no longer available in rawhide, considered private implementation
• Fedora rpm macros: %pom_*, %mvn_build, %mvn_install, %mvn_file
• xmvn-subst for dependency jars when packaging
• Fedora Java Packaging guidelines: https://fedoraproject.org/wiki/Packaging:Java JNI handling: System.load replaces System.loadLibrary, jar file in %{_jnidir} Jar files in %{_javadir}
• Fedora build systems have no internet access, avoid DNS if possible.
• Breaking apart or subsuming subelements
  • Depending on the popularity of a sub-element as a stand-alone package it sometimes makes more sense to break it out as a sub-package which can stand alone, but doesn't have to live in a separate repository. This is a choice which will have to be made by the upstream group and will depend heavily on their ideal workflow, but from a maintenance perspective it's far easier to maintain as a sub-package. E.g. one project produces multiple libs/jars.
• Fedora is OpenJDK7 or higher. You cannot mix-and-match usage of the Fedora versions of maven and ant with Java 6, since they are themselves compiled with source="1.7".