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
+1 g
On Tue, Apr 1, 2014 at 10:11 AM, Christopher ctubb...@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
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
+1 g
I hate working on packaging.
My customers don't want the current packaging.
On Tue, Apr 1, 2014 at 1:29 PM, John Vines vi...@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,
+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
+1 g
My $0.02: when I first started to use Accumulo (a little over a year ago),
I naively installed the RPM first, thinking, It's an RPM, it must be
easier! Turns out it wasn't easier, and it was in fact completely wrong.
If the community can't stand behind the packaging it creates as first
+1 to g
On Tue, Apr 1, 2014 at 10:11 AM, Christopher ctubb...@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.
+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 ctubb...@apache.org wrote:
RPM/DEB building in Maven is currently quite convoluted. There's some
question as
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
https://issues.apache.org/jira/browse/ACCUMULO-2606
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Apr 1, 2014 at 4:08 PM, Christopher ctubb...@apache.org wrote:
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
10 matches
Mail list logo
