accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject [DISCUSS] Drop RPM/DEB packaging from maven build
Date Tue, 01 Apr 2014 17:11:49 GMT
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

View raw message