accumulo-dev mailing list archives

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

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