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