Re: [Xen-devel] [PATCH] Add a "make rpmball" target

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 03/03/2014 08:51 PM, Don Slutz wrote:
> On 03/03/14 09:59, George Dunlap wrote:
> > Build a simplistic dummy package, similar to "make debball", for
> > developers on rpm-based systems.
> >
> > Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
> > ---
> > CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
> > CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > CC: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> > ---
> >   Makefile         |    7 +++++
> >   tools/misc/mkrpm |   82
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   2 files changed, 89 insertions(+)
> >   create mode 100644 tools/misc/mkrpm
> >
> > diff --git a/Makefile b/Makefile
> > index 4e48457..75e845b 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -152,6 +152,13 @@ world:
> >   debball: dist
> >       fakeroot sh ./tools/misc/mkdeb $(XEN_ROOT) $$($(MAKE) -C xen
> > xenversion | grep -v :)
> > +# Package a build in an rpmball file, that is inside a .rpm format
> > +# container to allow for easy and clean removal. This is not intended
> > +# to be a full featured policy compliant .rpm package.
> > +.PHONY: rpmball
> > +rpmball: dist
> > +    sh ./tools/misc/mkrpm $(XEN_ROOT) $$($(MAKE) -C xen xenversion |
> > grep -v :)
> > +
> >   # clean doesn't do a kclean
> >   .PHONY: clean
> >   clean::
> > diff --git a/tools/misc/mkrpm b/tools/misc/mkrpm
> > new file mode 100644
> > index 0000000..7d20788
> > --- /dev/null
> > +++ b/tools/misc/mkrpm
> > @@ -0,0 +1,82 @@
> > +#!/bin/sh
> > +#
> > +# mkrpm: package the dist/install output of a Xen build in an .rpm
> > +#
> > +# Takes 2 arguments, the path to the dist directory and the version
> > +
> > +set -e
> > +
> > +if test -z "$1" -o -z "$2" ; then
> > +  echo "usage: $0 path-to-XEN_ROOT xen-version"
> > +  exit 1
> > +fi
> > +
> > +xenroot="$1"
> > +
> > +cd $xenroot
> > +version=$2
> > +
> > +# Prepare the directory to package
> > +cd dist
> > +rm -rf rpm
> > +
> > +# Fill in the rpm boilerplate
> > +mkdir -p rpm/SPEC
> > +cat >rpm/SPEC/xen.spec <<EOF
> > +Summary: Xen development build, version $version
> > +Name: xen
> > +Version: $version
> > +Release: unstable
> > +License: GPL
> > +Group:   System/Hypervisor
> > +URL: http://xenbits.xenproject.org/xen.git
> > +
> > +BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
> > +%define __spec_install_post /usr/lib/rpm/brp-compress || :
> > +%define debug_package %{nil}
> Does this correctly stop the striping of debug symbols? Or does it just
> prevent the debuginfo packaging.
Don't know actually -- this was taken from the XenServer xen.spec.

> > +
> > +%description
> > +This package contains the Xen hypervisor and associated tools, built
> > +from a source tree.  It is not a fully packaged and supported Xen, just
> > +the output of a xen "make dist" wrapped in an .rpm to make it easy to
> > +uninstall.
> > +
> > +%build
> > +
> > +%install
> > +rm -rf \$RPM_BUILD_ROOT
> > +mkdir -p \$RPM_BUILD_ROOT
> > +cd %{_xenroot}
> > +dist/install.sh \$RPM_BUILD_ROOT/
> > +
> > +cd \$RPM_BUILD_ROOT
> > +
> > +# Don't include xen-syms
> > +rm -f boot/xen-syms*
> But this is an important file if you want to use crash on /proc/vmcore.
> So removing it for a developer rpm does not make sense to me.
Yes, you're right.  Actually, the reason I deleted this file is that the 
auto-install CentOS image I used to install my test machine creates a 
separate /boot partition that is tiny -- and if I included xen-syms, I 
couldn't install the rpm.
But that's something I should work around / fix in my own system.

> > +# Remove all the "linked" xen-*.gz files
> > +rm -f \$(find boot/ -type l)
> > +# Rename the real xen.gz binary, if necessary.
> > +if [[ ! -e boot/%{name}-%{version}-%{release}.gz ]] ; then
> > +    mv boot/xen-*.gz boot/%{name}-%{version}-%{release}.gz
> > +fi
> > +
> > +
> > +%clean
> > +rm -rf \$RPM_BUILD_ROOT
> > +
> > +%files
> > +%defattr(-,root,root,-)
> > +/*
> > +
> > +%post
> > +# Point xen.gz to the real binary.
> > +cd /boot
> > +ln -sf %{name}-%{version}-%{release}.gz xen.gz
> So 1st you unlink, then you make a new (maybe the same) link?
Again, this is an artifact of the way I had my system configured.  The 
reason I did this was so that I could install this while keeping the 
xen4centos xen-hypervisor package installed.  But I think you're right, 
it would be better to just uninstall the old package, and leave the 
links as they are.
Thanks for the review -- v2 coming soon.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel