[packagers] help with packaging an rpm

[Dag Wieers]

On Sat, 17 Nov 2007, Dave wrote:

>    This was originally posted to users but i was told of this list and thought
> it would be more appropriate for here.
>
>    I'm running CentOS 5 and wanting to make rpms out of some software for
> eventual inclusion in rpmforge. I've got some rpm urls i can scare them up if
> needed and have learned a lot reading them, at least i know the process.
>
>    The first package i'm trying to do is gnump3d as an rpm, and that's version
> 3.0. I've got the file and have created a .spec file. All goes well in the
> %prep stage, %build i've commented out as it isn't needed, the package is a
> perl base and all needs is a make install, which i handle in the %install
> section. I'm building as nonroot and the %install is failing when atempting to
> change permissions on a directory to 777, it's saying it doesn't have
> permission to do this. I thought i had my Buildroot defined wrong, so i looked
> at the samba rpm spec file and it was identical, so i am wondering what my
> issue is?

I assume that you are changing the real directories on the system, and not
the directories that are owned by your build-user in the %{buildroot}
directory.

As a normal user on the system you have no rights to modify system
directories (and that is *good* and a real reason to build as a user, not
as root).


>    I'm also going to have to patch the makefile or perform some other action
> on it. It defines the ManDir as /usr/local/man/man1 which is not standard, it
> works but i'd like this package to conform to rhel standards, i was thinking
> /usr/share/man/man1. Patch is new to me, perl is not, i could use a s//g;
> regexp in a one-liner to fix this, it seems simple, but it's beyound my
> knowledge at the moment.

Perl regexp is acually prefered, there are many examples in the rpmforge
repository. If you need examples, just check out the rpmforge tree and use
grep to find these examples.


>    Lastly for now my %files definition i've got all the directories needed,
> identified files as docs or configs but am not sure i got all of them. How can
> i be sure on this point?

If you miss files, RPM will complain that you have files in your
%{buildroot} that are not referenced in your %files section.

Empty directories (and directories in general) are ignored, so you have to
specify these specifically if you want them to be included. Especially
empty directories are therefor easy to miss in the final package.


>    I've included both the .spec file and the error typescript below.
>    This is a first draft of this specfile and my first rpm atempt, so i don't
> expect this to be pretty, accurate, frankly i'm surprised %prep worked, any


> gnump3d.spec
> #
> # Spec file for Gnump3d version 3.0
> # For CentOS5
> # May work on other RHEL or rpm-based distributions but i can not test it
> #
>
> Name: gnump3d
> Version: 3.0
> Release: 1
> Group: Applications/Internet
> #Group: Applications/Multimedia
> Distribution: CentOS Linux
> #Vendor:
> #Url:
> License: LGPL
> Summary: GNUMP3d - The GNU Streaming MP3 / OGG Vorbis Server.
> BuildRoot: %{_tmppath}/%{name}-%{version}-root
> Source: gnump3d-3.0.tar.gz

We follow a strict order of these headers (helps to find and
identify things things. We define 3 'paragraphs'.

  1. summary, name, version, release, license, group, url
  2. source, patch, buildroot
  3. buildarch, buildrequires, requires, provides, obsoletes

These 3 sections are seperated with a single blank line. The first section
is always fixed in size. The second and third section may grow depending
on the number of sources/patches and buildrequires/requires/...

In itself RPM does not mind, but it helps to have a structure.


> %description
> The Gnu Mp3d mp3 and Ogg Vorbis server.
>
> %prep
> %setup -q

We drop the -q, so that the buildlogs contains a list of files that come
from the tarball. This is not only useful for comparing 2 builds, this is
especially useful when debugging a build. Did I miss documentation files,
or there files I have to include myself manually, and so on...

The %prep section usuall is there to modify files before building,
commit patches, to create files or modify %{SOURCE?} or do whatever you
want to do in the location where the sources have been uncompressed.


> # %build
> #/bin/cp rcfiles/redhat /etc/init.d/gnump3d

The %build section is meant to do the actual (upstream) 'build'. Sometimes
this section is empty. Section name is optional, but we keep it even when
empty.


> %install
> make install
> # make install Prefix=$RPM_BUILD_ROOT/usr

The install phase _always_ starts with removing the %{buildroot}:

	%{__rm} -rf %{buildroot}

We use macros instead of real commands because macros can be modified in
the future to work in other environments. (eg. they can point to a
shell-wrapper to support the same options as in Linux)


> %clean
> rm -rf $RPM_BUILD_ROOT

We use the %{buildroot} macro for a multitude of reasons.


> %post
> /sbin/chkconfig --add gnump3d
>
> %preun
> if [ "$1" = 0 ] ; then
> /sbin/service gnump3d stop > /dev/null 2>&1
> /sbin/chkconfig --del gnump3d
> fi
> exit 0
>
> %files
> %defattr(-,root,root)
> /etc/gnump3d
> /usr/share/gnump3d
> /var/cache/gnump3d
> /var/cache/gnump3d/serving
> /usr/share/man/man1
> /var/log/gnump3d
> %doc /usr/share/man/man1/gnump3d.*
> %config /etc/gnump3d
> %config /etc/init.d/gnump3d
> %doc AUTHORS ChangeLog COPYING INSTALL README README.MacOSX README.Windows
> TODO
> %attr(0755, root, root) /etc/init.d/gnump3d
> %_mandir /usr/share/man

Here as well, we use macros for referencing standard autotools
directories.

-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]