accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Drop RPM/DEB packaging from maven build
Date Tue, 01 Apr 2014 20:08:54 GMT
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.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Tue, Apr 1, 2014 at 2:37 PM, Alex Moundalexis <alexm@clouderagovt.com> wrote:
> +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 <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
>>
>
>
>
> --
> Alex Moundalexis
> Solutions Architect
> Cloudera Government Solutions

Mime
View raw message