accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey+li...@cloudera.com>
Subject Re: [DISCUSS] Drop RPM/DEB packaging from maven build
Date Tue, 01 Apr 2014 17:59:19 GMT
+1 g

I like decoupling our build/release from packaging specific issues.

+0 e

If Christopher or someone else wants to use a contrib repo to manage the
packaging of Accumulo for some specific system, I think that's a fine thing
for a contrib repo to do.

-1 a-d, f

I don't want to delay 1.6 for packaging I and my customers won't use. I
don't want us to clutter our main repo with branches that aren't related
towards a core dev branch.

-Sean


On Tue, Apr 1, 2014 at 12:29 PM, John Vines <vines@apache.org> wrote:

> 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 <ctubbsii@apache.org> 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
> > http://gravatar.com/ctubbsii
> >
>

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