The unofficial guide to Building Yoper RPM's.

This is not endorsed or officially accepted by Yoper. Its just a collection of post from the Yoper Forums that I believe may help beginners to create RPM for Yoper.

1. Know you categories to avoid confusion.
2. The Yoper RPM creation howto.
3. If you prefer to use a simpler gui editor in place of vi here is how.
4. If you find the need to build an rpm that just places files in locations.
5. Adding desktop entries to your rpm. (piece borrowed from arklinux-thanks!)
6. Can't launch app after building it try this-

The Basics-

Back 1. Know your categories to avoid confusion-

1.YBase (core of the system)
includes-kernel,libs,development tools and languages, modules,file system support,bootloaders,etc.

2.Hardware (local and peripheral except networking:modem,nics,etc.)
includes-cdrom tools,printer related,partition tools,scanners,cameras,sound cards, midi, video camera,radio,etc.

3.GraphiX (System gui)
includes-sax2,Xfree86,KDE,Gnome,Window managers,Themes,icons sets,etc.

4.Administrative tools (system control not integral to a gui.)
includes-webmin, linuxconf, Yast, etc.

5.Networking (hardware and protocols)
includes-wireless,VLAN, nics, modem, ppp,ppoe,pptp,vpn,ipsec,httpd,ftpd,imap,pop3,sendmail,exim,Lampp,ssh,smb4k,firew
all, Ksambaplugin, etc.

6.Databases (servers and config tools)
includes-mysql, postgresql, sqlite, phpMyadmin, Oracle 9i, etc.

7.Production (communications and business suites)
includes- browsers except when integral to a gui, irc clients, e-mail clients, mozilla, opera, evolution, openoffice, star office, corel office, editors not integral to a gui, abiword, html editors, etc.

8.Education (instructional or research)
includes-astronomy programs: celestia, etc, Chemistry programs, Math tools, language tools, etc.

9.Multimedia (viewers and creators)
includes-music,video, graphics,:mplayer,xine,gimp,etc.

10.Games (games not integral to a gui)

Back The Yoper RPM creation howto

Yoper is able to cater for various package types as you know, but the preferred package type is rpm. We decided on rpm, since it allows the handling of dependencies in a better manner than tgz packages, which we used in V1. This way we were able to adopt the excellent apt update and install system originally developed for Debian and adapted by Connectiva Linux. Synaptic, also developed by connectiva is now our preferred GUI update tool. Any enhancement to that tool will benefit Yoper users and Connectiva users alike.

You might think that creating rpm's must be hard and tedious. I could not disagree more. Once you get used to this process you will certainly also find that you can compile dozens of packages in one go without really knowing too much on the ins and outs of it all. It is plain and simply straight forward if you are not afraid of the command line.

1.) Download the following 2 files and put them into


# Now cd into

cd /usr/src/yoper/SPECS
chmod +x rpmbuilder

2.) Download the following tar.bz2 file and put it into


3.) from within /usr/src/yoper/SPECS now run

./rpmbuilder binutils 2.15 Base

4.) This will create a spec file called binutils .spec and then open it with vi for you to adapt things to your liking. For example I want you to change the following entry that defines with Release number the package with a given version should have:

Release: 1

Please change it to 4.

5.) Now press Esc :wq

6.) The builder will ask you if you want to compile it, press enter:

7.) The package will now compile and depending on how fast your system is it will take a bit.

8.) Once it is finished you'll see onscreen the location of the new package in


the so called src rpm containing both the spec file you created is located here


9.) You can now install the package (in case Yoper does not have a higher version of this package) with

rpm -Uvh /usr/src/yoper/RPMS/i686/binutils-2.15-4.i686.rpm

10.) Template file explanation for those with problems/more interest

#Summary explaining in short what the package is about
Summary: A GROUP collection of binary Utilities
#name of the package usually the same name as the source
Name: NAME
#version of the package, usually the same version as the source
Version: VERSION
#Release tag. You can increase that each time you want the package to install onto #a system that has a previous release tag installed.
Release: 1
#License of the source you are compiling
Copyright: GPL
#Group Base in our example and will add it to the synaptic group
Group: GROUP
#macros are defined with %{} and these just replace the above values without you #doing a thing. You can add multiple entries like Source1, Source2 and so on.
#You might want to change this to gz in case you have a gz file and not a bz2 file
Source0: %{name}-%{version}.tar.bz2
# a Possible patch file gets added like this
#your website's address
#What distro you are building for
Distribution: Yoper
Placeholder for an icon file, not currentoy used in Yoper
#Icon: yoperlogo.xpm
#vendor of the software in question
Vendor: Yoper Limited
# you build it, hence put yourself in there
# This package provides something else and rpm can'f figure it out? Add it here
# This package requires something else and rpm can'f figure it out? Add it here
#Switch automatical detection of requirenments and provides off.
#AutoReqProv: no
#where you installing the package to be packaged: is for the #example /var/tmp/binutils-root
BuildRoot: %{_tmppath}/%{name}-buildroot
#The building of this package requires:
BuildRequires: bash, binutils, gcc, glibc, ncurses, make, tar, zlib, glibc

#Definitions are done like this
%define _unpackaged_files_terminate_build 1
%define _missing_doc_files_terminate_build 1
%define _smp_mflags -j8
%define _target_platform i686-pc-linux-gnu

#desctiption of the package
This is Your Operating System rpm spec file for NAME

#clean things up from a previous failed compile run
rm -rf $RPM_BUILD_DIR/%{name}*
rm -rf %{buildroot}

#unpack the source into /usr/src/yoper/BUILD
%setup -q
#possible apply the above patch

#configure the software (kde apps cannot have the --host --target entry.
CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
./configure --prefix=/usr --sysconfdir=/etc/ --host=%{_target_platform} --target=%{_target_platform} --disable-static --disable-debug

#build the software
make %{_smp_mflags}

#install into into /var/tmp/*
make install DESTDIR="$RPM_BUILD_ROOT"

#cleanup just in case something ends up in /usr/ instead of /usr/share
export SHARES="doc man info"

for i in $SHARES
if [ -e %{buildroot}/usr/$i ]
if [ ! -e %{buildroot}/usr/share/ ]
mkdir -p %{buildroot}/usr/share/
mv %{buildroot}/usr/$i %{buildroot}/usr/share/

#strip the binaries
find %{buildroot} -type f \
-exec /usr/bin/strip --strip-debug '{}' ';'

#clean the places out again
rm -rf $RPM_BUILD_DIR/%{name}*
rm -rf %{buildroot}

#add the following files to the repository

Back If you prefer to use a simpler GUI editor in place of vi here is how-

In the Yoper RPM creation howto, you use a in-shell editor called "vi" to edit the .spec file which describes what the RPM needs & programs display-info in Synaptic & other RPM installers. It's important to get the .spec file right, but I prefer to use a GUI text editor. So, here's the steps to change vi to another editor:

1) In a shell, find the path of your editor using which.
For me, it went like this:
tomB@yos ~ # which kwrite

Note: you might really not need the path, but it makes life easier in some ways. But if you can find a program in the path, it is installed & most likely set up right.

2) Edit the rpmbuilder file.
After the first "then" is a line starting with "vi" which we hate. Change out "vi" with the "/usr/bin/kwrite".

Back If you find the need to build an rpm that just places files in locations-

Original location -->

Building RPM Packages from Files other than Source Code

How to package binaries, data files, scripts etc into RPMs


The RPM packaging system is extensively used by lots of distro builders. Just browse through the installation CDs or ISO images from RedHat or Mandrake for example, and you'll find hundreds of RPMs. But not all these RPMs are application packages built from source code; some contain perl or python scripts and modules, others hold images, and some hold html documentation files. And while RPM is a very practical and convenient way of handling and distributing all sorts of file collections, most RPM documentation focuses on building application packages from source. In this page I'll try to show how easy it is to build RPM packages from files other than source.


Basically there are only three simple steps required:

  1. First, copy all the files that will make up your package into their proper places - ie. put them wherever you want RPM to install them. Don't forget to check that the files have suitable permissions set.
  2. Use your favourite text editor to write a spec file that lists the component files and any other necessary information. The spec file can be very simple; you can use the example below as a guide.
  3. Build the RPM package by using the command: rpmbuild -bb specfilename

After RPM has built the package you'll see a message showing where to find it; eg. "Wrote to /usr/src/RPM/RPMS/i586/".

Here is an example spec file, just replace the stuff in italics with your own.

Summary: A collection of hideous wallpapers
Name: UglyBackgrounds
Version: 1
Release: 0.01
Group: Graphical Desktop/Other
Packager: Johnno

Are you tired of cutesy, eye candy desktop images? Then you should install this
collection of truly horrible wallpapers.


Pretty simple eh? Note that entries are listed below their respective headers. Also note that if all the files are in one directory, you only need to list that directory instead of the individual files.


While the steps above will usually be enough to succesfully build a package, there are a couple of gotchas to keep in mind..


There are several things that can be added to our quick'n'dirty RPM to improve it, eg. shell scripts can be run before and/or after installation or uninstallation. They are commonly used for things like adding and removing menu entries, and can be existing scripts that are run simply by entering the scripts name under the appropriate line in the specfile, or you can put the script itself directly into the specfile. If you enter the actual script, it will be run under /bin/sh by default, so there is no need to put #!/bin/sh or whatever as the first line. Here are the entries to add to the specfile:

%pre (runs script just before installation)

%post (runs script just after installation)

%preun (runs script just before uninstallation)

%postun (runs script just after uninstallation)

Keep in mind that calling distro-specific scripts might make installation on other distros difficult, so you might want to test for the existance of these scripts before running them, rather than just running them directly.

You may also want to add a Requires: section. RPM will work out the dependancies for dynamic libraries and perl automatically, so only add what RPM won't detect itself.

Other Stuff to Consider

Before you rush into building, you should consider these points:

Further Info

Interested in learning more about RPM? You'll probably find these sites interesting..
Lessons in Packaging Linux Applications
The RPM HowTo - RPM at Idle
Mandrakes RPM HowTo

A more-or-less complete listing of the Linux-related stuff that I've written can be found at my homepage.

Back Adding a desktop entry-

Borrowed from -->  ( a very well done documentation)

Menu entry

Now we only need to create a desktop menu entry for our application, it is done by creating a special file called app-name.desktop (kimdaba.desktop) which contains some information. The menu entry should be created after the %install script as well.

# Create menu entry

mkdir -p $RPM_BUILD_ROOT%{_datadir}/applnk/Graphics

cat > $RPM_BUILD_ROOT%{_datadir}/applnk/Graphics/kimdaba.desktop <<EOF

[Desktop Entry]


GenericName=K Image Database

Comment=Manage your pictures easily

Exec=kimdaba %f






chmod 644 $RPM_BUILD_ROOT%{_datadir}/applnk/Graphics/kimdaba.desktop

The first thing we do is to make the directory, where the file will be placed, in our build tree. We use cat to create it here inside the spec file, we also could add it as a separate source, but i personally prefer it to be in the spec file. As you can see, it contains some information, about the name, the icon, etc. The Name is what will be displayed in our menu, and the GenericName is what will be under braquets just after the name. We finally set its permissions to 644, and that's it.

Back Can't launch app after building it try this-

kde applications are a little tricky ... remove

--host=%{_target_platform} --target=%{_target_platform}

from the spec file when building kde apps.

reinstall your rpm with

rpm -Uvh --force