RPM/DEB building in Maven is currently quite convoluted. There's some question as to whether we should even be performing this task or whether we should defer to downstream maintainers for system packaging. Whether or not we continue supporting RPM/DEB binary packages or if we defer that to downstream maintainers, we should probably not maintain them within the main maven build. Here's some reasons why:
1) The maven complexity is enormous, and every change to the binary tarball packaging requires an equivalent change in at least two more places: the RPM build config, and DEB build config. 2) The RPMs and DEBs have different packaging conventions, because their target systems have different packaging conventions. It's not easy to discern whether these differences are bugs or intended in the current scheme. 3) The breakage of the RPMs/DEBs should not block a release. They can be packaged after an official release, to correspond to the target systems. Changes to packaging should also not require a bump in the version of Accumulo itself. 4) The current scheme does not allow for source packages (deb sources and SRPMs) for rebuilding. 5) I don't know DEBs, and do not have the expertise necessary to maintain their packaging. Whoever knows DEBs probably does not know RPMs. Maintenance of these logically make more sense as contribs, maintained by their respective downstream maintainers. 6) DEBs may require packaging different init scripts for modern systems (upstart-compatible scripts for Ubuntu, systemd scripts for Fedora/RHEL7, or SysV init scripts for RHEL6). Convergence in our build is not possible, and would introduce even more complexity. There are many possible downstream maintainers: Apache BigTop, Linux distribution-specific maintainers, Homebrew formula maintainer for Mac, etc. We should make it easy for them to build their packages, but we should probably not be in the business of trying to create them in our build directly. It may be the case that supporting these different systems will still involve package maintainers who are also upstream developers... and that's fine. We could even create contrib repos for maintaining those things, but they should be separate from the upstream build. Currently, I believe the DEBs are broken... but I don't know exactly how, and don't know enough about DEB packaging to fix them (I could learn, but not without possibly delaying the 1.6.0 release). So, the question is, should we (select all that are appropriate): a) Fix before 1.6.0 is released. b) Release 1.6.0 and fix later. c) Include RPMs/DEBs in 1.6.0 release. d) Build packages within the main build. e) Create contrib repos for RPM/DEB packaging. f) Create contrib branches for RPM/DEB packaging. g) Strip them out and defer to whatever downstream maintainers decide to do. -- Christopher L Tubbs II http://gravatar.com/ctubbsii
