This section describes how GTK+ and GNOME packages are done on SUSE Linux. After the first part including basic information, there are some subsections describing more complicated or less common features, namely: Gconf, the GStreamer registry, and the shared MIME database.

The following basic rules are defined:

The packages needed for build must be mentioned in the neededforbuild line and in the BuildRequires tag. Two meta packages are defined: gtk2-devel-packages and gnome2-devel-packages, which can be used in the neededforbuild line. They substitute for packages needed for compilation of packages based on GTK+ 2.x and GNOME 2.x. The meta package gnome2-devel-packages includes only core libraries, including libgnomeprint, but not less common libraries, like gnome-panel, vte, and gail. Some other packages that are required at runtime but not for building are also not included, for example, some gdk-pixbuf loaders, fonts, and font database configuration.

Most GTK+ and GNOME packages use the standard configure, make, and make install technique. It is usually enough to set the right paths with configure options but no other special actions are necessary to locate GTK+ and GNOME. In this way, it is similar to other packages.

The related part of the spec file typically looks like:

%build
%suse_update_config -f
CFLAGS="$RPM_OPT_FLAGS” \
./configure --prefix=/opt/gnome \
        --libdir=/opt/gnome/%_lib \
        --sysconfdir=/etc/opt/gnome \
        --localstatedir=/var/opt/gnome
make

%install
make DESTDIR=$RPM_BUILD_ROOT install

In the example above, see how the $RPM_OPT_FLAGS are usually passed to configure. Also see that the macro %suse_update_config is usually called to update some auto-stuff related files.

Many GNOME packages use helper scripts or binaries installed in the libexec directory. They must call --libexecdir=/opt/gnome/lib/{name} where {name} usually is the package name. lib is used instead of %lib. See Section 4.1, “Biarch Systems” for more details. The configure options usually look like:

./configure --libdir=/opt/gnome/%_lib \
            --libexecdir=/opt/gnome/lib/%{name} \
            [...]

Packages providing GNOME applets can use --libexecdir=/opt/gnome/lib/gnome-applet. The directory is reserved for these applets.

All applications should install a .desktop file to define a menu entry. They must call the macro %suse_update_desktop_file for all installed menu entries in the %install section. This typical example is taken from the package planner:

%install
[...]
%suse_update_desktop_file %name Office ProjectManagement

Language-specific files (localizations of menu entries, messages, help content, etc.) should be marked with the respective %lang tag in the file list. There is the macro %find_lang for this purpose. It is typically used the following way:

%install
[...]
%find_lang %name

%files -f %{name}.lang
[...]

PreReq:       gconf2 gnome-filesystem

%post
export GCONF_CONFIG_SOURCE=`opt/gnome/bin/gconftool-2 \
                               –get-default-source`
opt/gnome/bin/gconftool-2 –makefile-install-rule \
    etc/opt/gnome/gconf/schemas/epiphany.schemas >/dev/null
opt/gnome/bin/gconftool-2 –makefile-install-rule \
    etc/opt/gnome/gconf/schemas/epiphany-lockdown.schemas \
    >/dev/null

%files
[...]
/etc/opt/gnome/gconf/schemas/epiphany.schemas
/etc/opt/gnome/gconf/schemas/epiphany-lockdown.schemas

/etc/opt/gnome/gconf/schemas/*.schemas

PreReq:       /opt/gnome/bin/gst-register
[...]

%post
opt/gnome/bin/gst-register >/dev/null

%postun
opt/gnome/bin/gst-register >/dev/null

%install
[...]
mkdir -p $RPM_BUILD_ROOT/usr/share
mv $RPM_BUILD_ROOT/opt/gnome/share/mime $RPM_BUILD_ROOT/usr/share

%install
[...]
cd $RPM_BUILD_ROOT/usr/share/mime
rm XMLnamespaces globs magic application/x-planner.xml

PreReq:       shared-mime-info
[...]

%post
usr/bin/update-mime-database /usr/share/mime >/dev/null

%postun
usr/bin/update-mime-database /usr/share/mime >/dev/null

%install
[...]
DESTDIR=$RPM_BUILD_ROOT mime-info-to-mime

Source1:      file-roller.xml
[...]

%install
[...]
mkdir -p $RPM_BUILD_ROOT/usr/share/mime/packages
cp %{S:1} $RPM_BUILD_ROOT/usr/share/mime/packages

This section describes how the kernel modules are packaged on SUSE Linux. More detailed information about the kernel can be found at http://www.suse.de/~agruen/kernel-doc/.

On SUSE Linux, packages providing kernel modules do not build them themselves. They create a subpackage with the kernel module sources (a binary RPM package with sources). Such packages are then installed when the kernel is built and the kernel modules are built together with the kernel binaries. Then the modules distributed under GPL are even packaged together with the kernel binaries. The others are put into a separate package with a name suffixed by -nongpl.

This approach has some advantages:

The following rules are defined for subpackages with kernel module sources:

The following example is taken from the package drbd, which provides a kernel module of the same name. Here are the related parts from drbd.spec:

Source1:      Makefile.module
[...]

%package -n km_drbd
Summary:      Sources for the drbd Kernel Module
Group:        Development/Sources

%description -n km_drbd
Sources for the drbd kernel module used to build SUSE kernels.

Authors:
--------
    Philipp Reisner <philipp.reisner@linbit.com>
    Lars Ellenberg <lars.ellenberg@linbit.com>
[...]

%install
[...]
mkdir -p $RPM_BUILD_ROOT/usr/src/kernel-modules/
cp -a drbd/. $RPM_BUILD_ROOT/usr/src/kernel-modules/drbd/
cp -a %{SOURCE1} \
      $RPM_BUILD_ROOT/usr/src/kernel-modules/drbd/Makefile
# Clean up, if anything was around by accident...
find $RPM_BUILD_ROOT/usr/src/kernel-modules \( -name '*.orig' \ 
        -o -name '*~' -o -name '.svn' \) \
        -print0 | xargs -0 rm -rf
[...]

%files -n km_drbd
%defattr(-,root,root)
%dir /usr/src/kernel-modules
/usr/src/kernel-modules/drbd

The required Makefile can already be a part of the original sources or it must be added to the package as an extra source. The example above shows the second variant.

The Makefile must provide the following targets:

The Makefile must use the following variables instead of exact paths. The variables are set correctly when the Makefile is called within the kernel and its modules are being built:

The target modules must be built with the following command to keep compatibility with regular kernel Makefiles:

$(MAKE) -C $(KERNEL_SOURCE) modules SUBDIRS=$(CURDIR)

The targets install and clean are added to improve convenience and consistency. This requires changes to the kernel build system that are done currently only in the SUSE kernel.

This is a template that can be used to create the required Makefile in km_* packages:

# Add the kernel makefile definitions first...

#  Set the place where to install the module(s)
#  below lib/modules/`uname -r`, it defaults to "extra".
MOD_DIR := some/where

.PHONY: modules install clean modules_add

install : modules_add

modules modules_add clean:
$(MAKE) -C $(KERNEL_SOURCE) $@ SUBDIRS=$(CURDIR)

This real example is taken from the package drbd. The file is installed as /usr/src/kernel-modules/drbd/Makefile:

# 
# SUSE specific makefile for the km_drbd
#

EXTRA_CFLAGS += -I$(src)

obj-m   := drbd.o
drbd-objs  := drbd_buildtag.o drbd_bitmap.o drbd_fs.o \
              drbd_proc.o drbd_worker.o drbd_receiver.o \
              drbd_req.o drbd_actlog.o lru_cache.o drbd_main.o

# Set to something different to install somewhere else:
# MOD_DIR := extra

.PHONY: modules install clean modules_add

install : modules_add

modules modules_add clean:
        $(MAKE) -C $(KERNEL_SOURCE) $@ SUBDIRS=$(CURDIR)

This section describes how Perl modules are packaged on SUSE Linux. The following rules are defined:

A dependency on Perl modules is not detected automatically. This means the packages must mention the necessary Perl modules in the Requires tag. This applies to the dependency between Perl modules as well.

The package perl need not be mentioned in the neededforbuild line because it is in the default set. However, it should be mentioned in the BuildRequires tag. This does not apply to the Perl modules. They must be mentioned in both places.

This example of a typical spec file preamble comes from the package perl-Inline-CPR:

# norootforbuild
# neededforbuild  perl-Inline perl-Parse-RecDescent
# usedforbuild    ... perl perl-Inline perl-Parse-RecDescent ...


Name:         perl-Inline-CPR
License:      Artistic License
Group:        Development/Libraries/Perl
Version:      0.12
Release:      151
Autoreqprov:  on
Requires:     perl = %{perl_version}
Requires:     perl-Inline
Summary:      Write Perl subroutines in C
URL:          http://cpan.org/modules/by-module/Inline
Source:       Inline-CPR-%{version}.tar.bz2
Patch:        Inline-CPR-%{version}.diff
BuildRoot:    %{_tmppath}/%{name}-%{version}-build

%description
This module allows you to program C in perl. See also perl-Inline.


Authors:
--------
    Brian Ingerson <INGY@cpan.org>

In the example above, see that two other Perl modules are needed for build and at run-time. They are mentioned by the neededforbuild line, BuildRequires tag, and the package perl-Inline is mentioned by the Requires tag. The second package perl-Parse-RecDescent need not be mentioned by the Requires tag because it is required already by perl-Inline.

Most Perl modules are built and installed a standard way. In addition, the macros %perl_make_install, %perl_process_packlist, %perl_vendorarch, and %perl_vendorlib are available. This makes it extremely easy to create a package. This approach is also used in the package perl-Inline-CPR from the example above. Here is the rest of its spec file:

%prep
%setup -n Inline-CPR-%{version}
%patch

%build
perl Makefile.PL
make
make test

%install
%perl_make_install
%perl_process_packlist

%clean
rm -rf $RPM_BUILD_ROOT

%files 
%defattr(-, root, root)
%doc Changes README MANIFEST
%{perl_vendorlib}/Inline/CPR*
%{perl_vendorarch}/auto/Inline/CPR
/var/adm/perl-modules/%{name}

In the example above, see how the macro %perl_process_packlist is used. It removes $RPM_BUILD_ROOT from some files and allows packing the file %perl_archlib/perllocal.pod as /var/adm/perl-modules/%{name}. See Section 3.15, “%perl_process_packlist” for more details.

SuSEconfig --module perl should be called after installing the package. It updates the %perl_archlib/perllocal.pod from the information saved in /var/adm/perl-modules. It is not called from the %post script because it would take ages if several packages are installed at once and each of them called this script independently.

If a module includes a part written in C, the $RPM_OPT_FLAGS can usually be passed the following way. The example is taken from the package perl-Bit-Vector:

%build
perl Makefile.PL OPTIMIZE="$RPM_OPT_FLAGS -Wall"
make
make test

This section describes how Python modules are packaged on SUSE Linux. The following rules are defined:

The packages python and python-devel are usually needed to build. They need to be mentioned in the line neededforbuild and defined in the tag BuildRequires.

This example of a typical spec file preamble comes from the package python-numeric:

# norootforbuild
# neededforbuild  python python-devel

BuildRequires: aaa_base ... python python-devel ...

Name:         python-numeric
License:      BSD, Python
Group:        Development/Libraries/Python
Version:      23.3
Release:      1
Autoreqprov:  on
%py_requires
Summary:      A Numerical Extension to Python
URL:          http://sourceforge.net/projects/numpy
Source:       Numeric-%{version}.tar.bz2
Patch:        Numeric-%{version}-noatlas.patch
BuildRoot:    %{_tmppath}/%{name}-%{version}-build

%description
Numerical Python adds a fast and compact multi-dimensional array
language facility to Python.

Authors:
--------
    numpy-developers@lists.sourceforge.net

Most Python modules use distutils now, so it is extremely easy to package them. This feature is documented at http://www.python.org/sigs/distutils-sig/. It is also used in the package python-numeric from the example above. Here is the rest of its spec file:

%prep
%setup -n Numeric-%{version}
%patch

%build
export CFLAGS="$RPM_OPT_FLAGS"
python setup.py build

%install
python setup.py install --root=$RPM_BUILD_ROOT \
       --record-rpm=INSTALLED_FILES

%clean
rm -rf $RPM_BUILD_ROOT

%files -f INSTALLED_FILES
%defattr(-,root,root)
%doc README changes.txt Demo

In the example above, see how the variable $RPM_OPT_FLAGS is usually used to build binaries. Also see in the install command that the option --record-rpm can be used to create a file list that is then used in the %files section. This feature currently exists only in SUSE Python packages. A patch for upstream is waiting for review.

If a package uses a nonstandard build method, the special RPM macros %py_ver, %py_incdir, %py_libdir and %py_sitedir can be used to get the location of Python directories.

This example is taken from the package python-fcgi:

Source0:      http://alldunn.com/python/fcgi.py
[...]

%prep

%build

%install
install -m755 -d $RPM_BUILD_ROOT/%{py_sitedir}
install -m644 %{S:0} $RPM_BUILD_ROOT/%{py_sitedir}
python%{py_ver} %{py_libdir}/compileall.py -d %{py_site}/ \
   $RPM_BUILD_ROOT/%{py_sitedir}

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root)
%{py_sitedir}/fcgi.py*