[DISCUSS] Drop RPM/DEB packaging from maven build

[Christopher <ct...@apache.org>]

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

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Mike Drob <ma...@cloudera.com>]

+1 g


On Tue, Apr 1, 2014 at 10:11 AM, Christopher <ct...@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
>

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Eric Newton <er...@gmail.com>]

+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, 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 <ct...@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
> >
>

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Michael Allen <mi...@sqrrl.com>]

+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
class installation options, it should not package the software that way at
all.  For all the reasons above, it sounds like a mess.


On Tue, Apr 1, 2014 at 1:59 PM, Sean Busbey <bu...@cloudera.com>wrote:

> +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 <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, 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 <ct...@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
> > >
> >
>



-- 

*Michael Allen*
Security Architect | Sqrrl-----------------------------------130
Prospect Street | Cambridge, MA 02139415.699.0106 | www.sqrrl.com
-----------------------------------

The information contained in this communication may be confidential,
subject to legal privilege, or otherwise protected from disclosure,
and is intended solely for the use of the intended recipient(s). If
you are not the intended recipient of this communication, please
destroy all copies in your possession, notify the sender that you have
received this communication in error, and note that any review or
dissemination of, or the taking of any action in reliance on, this
communication is expressly prohibited.  Please note that sqrrl data,
INC. reserves the right to intercept, monitor, and retain e-mail
messages to and from its systems as permitted by applicable law.

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Sean Busbey <bu...@cloudera.com>]

+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 <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, 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 <ct...@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
> >
>

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[John Vines <vi...@apache.org>]

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 <ct...@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
>

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Christopher <ct...@apache.org>]

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 <ct...@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 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 <al...@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 <ct...@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

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Christopher <ct...@apache.org>]

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 <al...@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 <ct...@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

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Alex Moundalexis <al...@clouderagovt.com>]

+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 <ct...@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

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Bill Havanki <bh...@clouderagovt.com>]

+1 g, -1 a/c/d/f


On Tue, Apr 1, 2014 at 2:14 PM, Billie Rinaldi <bi...@gmail.com>wrote:

> +1 to g
>
>
> On Tue, Apr 1, 2014 at 10:11 AM, Christopher <ct...@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
> >
>



-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

Re: [DISCUSS] Drop RPM/DEB packaging from maven build

[Billie Rinaldi <bi...@gmail.com>]

+1 to g


On Tue, Apr 1, 2014 at 10:11 AM, Christopher <ct...@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
>