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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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
