Re: [PATCH] Add a "make rpmball" target

[George Dunlap <george.dunlap@eu.citrix.com>]

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@eu.citrix.com>
>> ---
>> CC: Ian Jackson <ian.jackson@citrix.com>
>> CC: Ian Campbell <ian.campbell@citrix.com>
>> CC: Dario Faggioli <dario.faggioli@citrix.com>
>> ---
>>   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