If you count the most prominent and well-known Linux distributions, you’ll notice that nearly all of them utilise two software package types: DEB or RPM. The first one comes from the world of Debian and spreads on Ubuntu and dozens of its derivatives, while the RPM, originally created for Red Hat, is used in Fedora, Mageia, OpenSUSE and many others. Both worlds share the same approach: every file in a system must belong to a package, so the whole installation is a collection of binary packages.
Maybe you’re already familiar with building Linux applications from source, or you just want to deliver a custom set of files or a binary app in the ‘right’ way – neat, clean and convenient. In this tutorial we will find out what it takes to create a custom DEB or RPM package and the ways in which you can benefit from maintaining everything in your system by using packages.
The tutorial naturally breaks into two parts, as Debian and Red Hat packaging systems are different and therefore require learning different sets of commands. However, as you will see a bit later, the procedure is really straightforward and easy to follow once you have got your head around just a
few basic examples.
1. Why you may need to do it
Let us first list some common cases where packing your files into a package is preferred. To start with, your distribution may lack some packaged application that you need, so you may try to build it from scratch (the hard way) or adapt a similar package from another distribution (generally, the preferred way). Next, not all software is open source, so you may pack a binary-only application or even a set of random files and make them installable with a few clicks of your mouse. This is often needed to deliver some proprietary, yet popular, software items such as the Vivaldi browser or Skype VoIP application.
2. The inside of RPM
When you double-click an RPM file it will probably be opened in a software installing tool, but you can always open it as an ordinary archive. File Roller or Ark will open an RPM just the same way as they would open a ZIP archive. However, while you’ll see the file tree, there’s more to RPM as it includes scripts that enable extra actions with files, such as fixing permissions, copying and removing files, or any other custom action in Bash.
Whatever architecture an RPM file is designed for, be it x86_64, i586 or noarch, it is generated from a source RPM, also known as SRPM. It contains the sources of the application and a spec file, which defines all the commands and routines that you will need to compile it into the target RPM file. If you need to re-pack a proprietary application, sometimes only a properly written spec file is required, as it obtains the app files automatically.
3. Compile RPM from a source RPM
For the impatient, the command is simply: rpmbuild –rebuild /tmp/mypackage-1.0.0-1.src.rpm. Another way is to install the source package as follows:
rpm -i /tmp/mypackage-1.0.0-1.src.rpm
… and then address the spec file directly:
cd ~/rpmbuild/SPECS && rpmbuild -ba mypackage.spec
Take note that all commands should be issued under a regular user account and not root, due to security reasons.
To make things work, you’ll need the rpm-build package and all development libraries and compilers required to build the sources of your application. If you’re recompiling something that is already present in your system’s repositories, you may try zypper si -d mypackage in OpenSUSE, urpmi
–buildrequires mypackage in OpenMandriva/Mageia, or yum-builddep mypackage in Fedora.
As you noticed, the contents of the src.rpm file is unpacked into the rpmbuild directory inside your home folder (~). This is where the standard tree of an RPM packager resides, along with a full set of subdirectories: build, buildroot, rpms,
source, specs, srpms.
4. Writing a dummy spec
The image on page 24 illustrates a simple dummy spec file, which can be compiled into an RPM containing two files: dummy.file and dummy.another.file. To make things work before you launch rpmbuild, put these files into the %{buildroot}/etc/dummy directory. During the build process rpmbuild may complain on some minor issues, which sum into the badness score. If the score surpasses a certain threshold then the build will fail. Of course it’s best to fix problems rather than to override the score, but in case you need the latter choice, use the setBadness command in your spec. For example, to enable building a package that includes an unauthorised permissions file, add the following line:
setBadness(‘permissions-unauthorized-file’, 0).
5. A simpler way: use checkinstall
Use checkinstall instead of make install when you build an application or a library from source. Checkinstall works in Debian and Red Hat, where it asks you for some details (package name, version, description, etc) and automatically produces a package. The main benefit is that you can keep your system clean and tidy. If you need to wipe off the files, simply remove the package with your standard package manager tool (urpme, zypper rm, yum remove). The downside of checkinstall is its limited features. For example, you can’t include post-installation scripts with it and so it won’t work when packaging some proprietary apps, as it needs extra hooks for many systems. However, checkinstall is perfect for local installations or small OEM tasks, so try it.
6. A brief look at handling the .deb format
Just like with RPM, DEB files can be opened with archive managers so that you can see the two other tarballs: data.tar.gz and control.tar.gz. They are pretty self-explanatory – the first one contains package files, the second one contains package metadata. Building DEB packages is different from RPM but still straightforward. It is even more standardised because in Debian/Ubuntu and their clones there is one dominating technology to handle deb packages – apt plus dpkg. Apt is a powerful tool for handling packages and repositories and it has various companions, such as aptitude for flexible search queries, while dpkg is solely a package management tool (similar to the rpm command).
7. Build DEB packages
First, get the essentials:
sudo apt-get install autoconf automake libtool
autotools-dev dpkg-dev fakeroot dh-make
Imagine, for example, you’ve got mypackage-0.0.2.tar.gz, which you wish to compile into a DEB package. First, prepare a build directory manually like this:
mkdir -p ~/src/mypackage/0.0.2
Then put your tarball into that directory and unpack it (tar xzf mypackage-0.0.2.tar.gz). Then you will need to compile the program using classic commands:
./configure –prefix=/usr && make
If you’re recompiling a program that already exists in one of your repositories, you can ease the development dependency resolution by issuing apt-get build-dep mypackage beforehand in order to make the ./configure script run more smoothly.
8. Debianise it
Run dh_make –createorig, answer a few questions about the package’s details and finally hit Enter. You will see the newly created debian subdirectory added to the sources tree. Edit the debian/control file and modify the package description if necessary. Now, make sure you’re currently in the main sources directory and issue the command:
dpkg-buildpackage -rfakeroot
After a while, once the building process is over, move a level up and enjoy your newly created DEB package. You can double-click it or use the dpkg -I mypackage-0.0.2*.deb command.
Notice the .dsc file, which can help you pull the application sources in future. The syntax looks like this:
dpkg-source -x ./mypackage-0.0.2.dsc
9. The graphical way
Debreate is graphical tool and step-by-step wizard for those who want to avoid the command line fu. You can download and install Debreate from its official mirror (bit.ly/1ItNSPQ) – it is a universal .deb package itself and suitable for nearly all systems.
On the Control tab you are supposed to fill in the info and description fields, much like you would do if you were in the debian/control file.
The Dependencies and Conflicts tab enables you to specify package requirements or conflicts, including specific minimum versions. After that, select the package contents on the Files tab, include optional post-installation commands on the Script tab, create a desktop menu entry on the Menu tab and finally press the big green button on the Build tab to generate the DEB package. With this tool, it should be both faster and easier to create a Debian package.
from Linux User & Developer – the Linux and FOSS mag for a GNU generation http://ift.tt/1S8tw3u
via IFTTT
Posts
No comments:
Post a Comment