accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Moundalexis <>
Subject Re: [DISCUSS] Drop RPM/DEB packaging from maven build
Date Tue, 01 Apr 2014 18:37:41 GMT
+1 g (non-binding)

consolidated packaging efforts are usually far better than one-off
attempts, plus it'll clean up the repo a little bit

On Tue, Apr 1, 2014 at 1:11 PM, Christopher <> wrote:

> 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

Alex Moundalexis
Solutions Architect
Cloudera Government Solutions

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message