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.
I opt for g- lets rip them out now. They're horrendous in their current state. Realistically we should have our debs/rpms based off a tarball, not so tightly integrated with each module of maven. So it makes sense for there to be something downstream which can use a tarball and spits out an rpm and a deb.
Also, worth noting for 6- when I wrote the initial init.d scripts and the script installer, they were for deb and not rpms. I then made them universal (ish, I might have messed something up, but they worked for me in ubuntu and centos). Whether or not someone broke that in the meantime is the current question. On Tue, Apr 1, 2014 at 1:11 PM, Christopher <[EMAIL PROTECTED]> wrote:
My $0.02: when I first started to use Accumulo (a little over a year ago), I naively installed the RPM first, thinking, "It's an RPM, it must be easier!" Turns out it wasn't easier, and it was in fact completely wrong. If the community can't stand behind the packaging it creates as first class installation options, it should not package the software that way at all. For all the reasons above, it sounds like a mess. On Tue, Apr 1, 2014 at 1:59 PM, Sean Busbey <busbey+[EMAIL PROTECTED]>wrote:
*Michael Allen* Security Architect | Sqrrl-----------------------------------130 Prospect Street | Cambridge, MA 02139415.699.0106 | www.sqrrl.com
The information contained in this communication may be confidential, subject to legal privilege, or otherwise protected from disclosure, and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this communication, please destroy all copies in your possession, notify the sender that you have received this communication in error, and note that any review or dissemination of, or the taking of any action in reliance on, this communication is expressly prohibited. Please note that sqrrl data, INC. reserves the right to intercept, monitor, and retain e-mail messages to and from its systems as permitted by applicable law.
Okay, so it sounds like there's a pretty big backing to rip this out. I'll create a JIRA and remove them from the main build. I'll probably set up a repo on github to maintain a SPEC file for building RPMs from the binary tarball, for now. We can consider incorporating them as a contrib project later.
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext