The concept of providing an RPM/Deb release option is perfectly fine from my POV, this would require opening issues in Jira to add these release targets. A quick search turns up a Maven rpm plugin (http://mojo.codehaus.org/rpm-maven-plugin/) that may be used to keep our release process streamlined. There may be other methodologies available that we should consider as well (http://www.rpm.org/max-rpm-snapshot/rpmbuild.8.html).
A couple of things we'd also have to check is how we can sign these artifacts in accordance with ASF procedures, update release process to reflect any new steps, and test our new RPMs. One thing I would like to do before hand however is see how other Apache projects provide RPMs. Far as I can tell RPMs are being provided by other groups (i.e., HTTPD and Tomcat can be found as RPMs but the project pages do not have links for obtaining them, OpenOffice seems to be one of the few to list these other packages http://www.openoffice.org/download/other.html). We need to check if there are any guidance from the ASF regarding their standards for RPM/Deb/DMG/etc package releases. Cheers, Jamie On Tue, Jan 15, 2013 at 10:54 PM, Andreas Pieber <anpie...@gmail.com> wrote: > TBH I'm still not against the idea of having deb/rpm for Karaf. So the > release manager would > > a) run "mvn release:prepare ... " > b) scripts/rpmPackaging.sh > c) deploy the final artifact to a rpm repo? Or simply provide it for > download with the rest of the distribution in hope someone will pick > up the package and distribute it to their favorite repos? > > Feel free to correct me, but it sounds reasonable to me. BUT the > decision need to be made by our release managers: > > @Jamie: WDYT? > > Kind regards, > Andreas > > p.s.: yes, please create an issue with this script anyway. Would make > it ways easier to find later on. > > On Tue, Jan 15, 2013 at 6:37 PM, aj...@virginia.edu <aj...@virginia.edu> > wrote: >> That's simpler than distributing an RPM to the repos, by a long ways. With >> that approach, all we'd need would be the spec (build) script. I append the >> example at the end of this email. As you can see, it's not very much. I'm >> sure it could be better written (I'm no RPM "maven" {grin}) but it's a place >> to start. I used the Tanuki Java wrapper as part of the dependency, because >> that software is commonly available for almost any Linux distro. I also >> included a separate body of source for the package (shown below as >> "wrapper-gear") which is just the files that Karaf creates from its >> "wrapper: " commands. These two inclusions allow the RPM to install Karaf as >> a Linux system service using the Tanuki wrapper. >> >> Graham-- I'll send you a tarball of "wrapper-gear" off-list, just so you can >> see what I did. >> >> It's this worthy of opening an issue? >> >> --- >> A. Soroka >> Software & Systems Engineering :: Online Library Environment >> the University of Virginia Library >> >> On Jan 15, 2013, at 12:26 PM, Graham Leggett wrote: >> >>> On 15 Jan 2013, at 7:09 PM, aj...@virginia.edu wrote: >>> >>>> I have, for local consumption. I based the build on an ActiveMQ RPM >>>> script. It wasn't too difficult and I can send you the example, if you >>>> like. >>> >>> If you can, I would hugely appreciate it. >>> >>>> There has been discussion before on this list about maintaining a >>>> semi-"blessed" RPM of Karaf directly from the project. I'd be happy to >>>> work on that, if I could get guidance and help integrating it into the >>>> release process. >>> >>> I maintain the spec file that is shipped with Apache httpd, the idea is >>> that you can download a httpd tarball and run "rpmbuild -tb <tarball>" and >>> it "just works". All that is required is that a file called <package>.spec >>> exists in the root of the tarball. (It might also work if the spec file is >>> elsewhere in the tree, but I've not tried). >>> >>> I am busy looking at the jpackage version of karaf, and it seems to have a >>> significantly different structure to that shipped by Apache. Still need to >>> get my head around it. >>> >>> Regards, >>> Graham >>> -- >>> >> >> [ajs6f@esbdev2 SPECS]$ cat apache-karaf.spec >> >> # turn off Red Hat's jar repacking macro >> %define __jar_repack %{nil} >> >> # >> # Spec file for packaging Apach Karaf >> # >> Summary: Apache Karaf >> Name: apache-karaf >> Version: 2.2.7 >> Release: 1 >> License: Apache >> Group: Networking/Daemons >> Source0: >> http://www.apache.org/dyn/closer.cgi/karaf/2.2.7/apache-karaf-2.2.7.tar.gz >> Source1: wrapper-gear >> >> URL: http://karaf.apache.org/ >> Vendor: Apache Foundation >> Packager: A. Soroka <aj...@virginia.edu> >> BuildArch: noarch >> Requires: java >> Requires: tanukiwrapper >> >> %description >> Apache Karaf is a small OSGi runtime which provides a lightweight container >> into which various components and applications can be deployed. >> >> %define karaf_home /usr/share/karaf >> %define karaf_data /var/cache/karaf >> %define karaf_config /etc/karaf >> %define karaf_deploy /var/local/karaf-deploy >> %define karaf_startuplib /usr/local/lib/karaf >> %define karaf_systemlib /usr/local/lib/karaf-system >> %define karaf_logs /var/log/karaf >> >> %prep >> %setup >> >> %build >> # No build needed for a pure-Java application like Karaf >> /bin/true >> >> %install >> >> # Add the "karaf" user and group >> # the "|| :" ("or NOP") on the end allows for the condition that this user >> and group already exist >> /usr/sbin/groupadd --system karaf 2> /dev/null || : >> /usr/sbin/useradd --comment "Apache Karaf" -g karaf \ >> --shell /bin/bash --system --home-dir %{karaf_home} karaf 2> /dev/null >> || : >> >> # We put the various pieces of Karaf into FHS-appropriate places, then symln >> them >> # together in /usr/share/karaf. >> >> # First copy all of the Karaf tree into %{karaf_home} (should be >> /usr/share/karaf) >> mkdir -p $RPM_BUILD_ROOT%{karaf_home} >> mv --verbose * $RPM_BUILD_ROOT%{karaf_home}/ >> >> # Now we make the FHS locations for Karaf stuff >> mkdir -p $RPM_BUILD_ROOT%{karaf_config} $RPM_BUILD_ROOT%{karaf_deploy} >> $RPM_BUILD_ROOT%{karaf_deploy} \ >> $RPM_BUILD_ROOT%{karaf_startuplib} $RPM_BUILD_ROOT%{karaf_systemlib} >> $RPM_BUILD_ROOT%{karaf_data} \ >> $RPM_BUILD_ROOT%{karaf_logs} $RPM_BUILD_ROOT/etc/init.d >> >> # Now we move pieces of the tree out of there into FHS-appropriate spots and >> re-symln them >> >> pushd $RPM_BUILD_ROOT%{karaf_home} >> mv etc/* $RPM_BUILD_ROOT%{karaf_config} >> rmdir etc >> ln -s %{karaf_config} etc >> mv deploy/* $RPM_BUILD_ROOT%{karaf_deploy} >> rmdir deploy >> ln -s %{karaf_deploy} deploy >> mv lib/* $RPM_BUILD_ROOT%{karaf_startuplib} >> rmdir lib >> ln -s %{karaf_startuplib} lib >> mv system/* $RPM_BUILD_ROOT%{karaf_systemlib} >> rmdir system >> ln -s %{karaf_systemlib} system >> popd >> >> # Karaf logs show up in the data dir by default, so we make a symlink >> ln -s %{karaf_logs} $RPM_BUILD_ROOT%{karaf_data}/log >> >> # Tanuki wrapper configuration >> cp -v %{SOURCE1}/karaf-wrapper.conf >> $RPM_BUILD_ROOT/etc/karaf/karaf-wrapper.conf >> >> # init.d script >> cp -v %{SOURCE1}/karaf $RPM_BUILD_ROOT/etc/init.d/karaf >> >> # Java to support Wrapper operation >> cp -v %{SOURCE1}/*.jar $RPM_BUILD_ROOT%{karaf_startuplib} >> >> %post >> # install Karaf service (but don't activate) >> /sbin/chkconfig --add karaf >> >> %preun >> # turn off Karaf and remove it from the init.d services before uninstalling >> if [ $1 = 0 ]; then >> /etc/init.d/karaf stop >> /sbin/chkconfig --del karaf >> fi >> >> %files >> %doc %{karaf_home}/karaf-manual-2.2.7.pdf >> %doc %{karaf_home}/karaf-manual-2.2.7.html >> >> # Karaf startup script (uses Tanuki wrapper) >> %attr(755, root, root) /etc/init.d/karaf >> >> # Karaf configuration >> %config(noreplace) %attr(775, root, karaf) %{karaf_config} >> >> # Karaf bundle cache, ActiveMQ data, etc. This is the real location of >> KARAF_DATA >> %attr(775, karaf, karaf) %{karaf_data} >> >> # Karaf hot deploy directory >> %attr(775, karaf, karaf) %{karaf_deploy} >> >> # Karaf logs >> %attr(775, karaf, karaf) %{karaf_logs} >> >> # Karaf startup libraries >> %attr(755, root, root) %{karaf_startuplib} >> >> # Karaf packaged Maven repo. Most of Karaf code is here, not in the startup >> libraries >> %attr(755, root, root) %{karaf_systemlib} >> >> # Full of symlinks to files above, plus demos, a README or two, etc.: this >> is treated as KARAF_HOME and KARAF_BASE >> # we have to leave it writeable by the karaf group in order for user karaf >> to create the Karaf lockfile >> # (which should eventually move to KARAF_DATA: see >> https://issues.apache.org/jira/browse/KARAF-579) >> %attr(775, root, karaf) %{karaf_home} >>
