Introduction
- Who should read this?
- Why APT for RPM?
APT, the concept
Getting APT
Using APT
APT Repositories
- Picking up repos
- Some repos for you
Final words

Introduction

A few days ago, I posted an article about packaging, specifically about using checkinstall to keep all your installed software under at least some sort of management.

Now, I will talk about a set of tools to help you install and uninstall software easily: APT.

Who should read this?

All you Debian guys: you already know APT, you are not going to learn anything new here, so you can leave.

All the Gentoo guys: you use emerge (for some reason), you are not going to like this, so you can leave, too.

This article is oriented to Red Hat users, Fedora Users, and probably users of other RPM-based distros (but for them, the repositories are wrong, sorry!).

Why APT for RPM?

While the Red Hat and Fedora distros work, the tools provided for package management suck. Sure, up2date works. Sure, RPM works. Sure system-config-packages work.

But:

system-config-packages is slow, is geared to stuff that came with the distro, and pretty much sucks for anything else.
up2date sucks the same way, only over the network (yes, I know you can set up your own up2date repository).
RPM is too low level, lacking any sort of dependency checking and being basically obnoxious.

The solutions are APT or yum. I like APT better, so there.

APT, the concept

APT works with the concept of repositories.

Suppose you want to use MPlayer. It's a fine tool, but building it from source to its full potential is a chore, since it has about a trillion requirements, from windows codecs to ffmpeg to opendivx, to sdl, to aalib to whatever.

So, how do you install all those things in a basic RPM system? You get each one from somewhere (hopefully in packaged form) along with their matching -devel packages, and install them. Then you build MPlayer, and if you are lucky, you didn't forget anything you may want to have next week.

But think about it: if MPlayer was a RPM instead of a source package, it would contain information about its requirements, right? That's one of the useful things about packages.

What it won't have is information about where you can get those packages, and RPM lacks the smarts to figure it out.

So, what APT does is, you feed it a list of repositories, which are simply web or ftp servers that have a collection of packages in them and some extra files, so that if you download that data, you know:

What packages are in the repository.
What each package requires
What each package provides

So, using APT, you tell it, "I want MPlayer". APT knows MPlayer is in the repository (because of item 1), knows what packages should be installed so that MPlayer works right (item 2), knows how to get them (again item 1), and so on.

Then, your computer gets a whole lot of RPM files, installs them, and you start watching movies.

Getting APT

Obviously, there is one package you just can't get over APT, which is APT itself (at least the first time ;-).

There are several places where you can download it, but I use freshrpms. Just follow the link for your verson of Red Hat or Fedora, and download the apt-xxxxx.i386.rpm file.

Once you have it, install it using RPM:

    rpm -Uvh apt-xxxxx.i386.rpm

And that's that, you have APT installed.

Using APT

The command line

The basic usage from the CLI is so simple, if you have been installing stuff using bare RPM, you gonna want to kick yourself in the teeth

First, you need to tell APT to fetch the current list of packages from the repositories. This has to be done every once in a while, since new packages and new versions appear very often. Normally, I just put it on a cron job at night.

    apt-get update

Once you did that, if you want to install a package (say, MPlayer)

    apt-get install mplayer

Wait a little, answer any questions, wait a little more, and that's it. If you already have MPlayer, but want to update it, it's the exact same thing as installing it.

Updating everything in your box? Well, there are two commands you can use:

    apt-get upgrade
    
    apt-get dist-upgrade

Should you use one or the other? Well, dist-upgrade is smarter, and handles major upgrades better, but it's a little more prone to getting into conflicts. On the other hand, upgrade sometimes doesn't upgrade everything, and you need to upgrade a few packages individually later (no big deal, anyway).

Just try it, you won't break your system, usually.

But the above assumes you know what you want to install. How can you know what is available?

Well, you can look at the next section about using a graphical tool, but here's a proposal: what do you want to do?

Do you want to play a DVD? Well, then just search for DVD in apt's database of package repositories using apt-cache:

    [root@roberto weblog]# apt-cache search dvd
    a52dec - Library for decoding ATSC A/52 (aka AC-3) audio streams
    a52dec-devel - Development header files and static library for liba52
    gstreamer-plugins-extra-dvd - DVD plugins for GStreamer
    libdvdcss-devel - Development files from the libdvdcss DVD decryption library
    libdvdnav - DVD menu navigation library
    libdvdnav-devel - Development files for the libdvdnav DVD menu navigation library
    libdvdplay - Library designed for DVD navigation
    libdvdplay-devel - Development files from the libdvdplay DVD navigation library
    libdvdread - Library for reading DVD video disks
    libdvdread-devel - Development files from the libdvdread library
    ogle - DVD player that supports DVD menus
    ogle_gui - Graphical user interface for the ogle DVD player
    perl-Video-DVDRip - Graphical DVD ripping tool based on transcode
    subtitleripper - DVD subtitle ripper
    transcode - Linux video stream processing utility
    videolan-client - The VideoLAN client, also a very good standalone video player
    videolan-client-devel - Header files and static library from the Videolan Client
    xine - Free multimedia player
    xine-lib - Core library of the xine multimedia player
    xine-lib-devel - Development files for the xine library
    dvd+rw-tools - Toolchain to master DVD+RW/+R media
    radvd - A Router Advertisement daemon
    gstreamer-plugins - GStreamer Streaming-media framework plugins
    k3b - CD/DVD burning application for KDE
    libdvdcss - A portable abstraction library for DVD decryption.
    cdrecord - A command line CD/DVD recording program.
    dvdrecord - A command line CD/DVD recording program.
    libpostproc - Video postprocessing library from MPlayer.
    kaffeine - A xine-based Media Player for KDE
    mplayer - MPlayer, the Movie Player for Linux.

As you can see, you get a list of packages that seem related to the search term. Since each package has to contain a description, one would expect all these are somewhat related to DVDs.

Want more details on one of them? As for it!

    [root@roberto weblog]# apt-cache show kaffeine
    Package: kaffeine
    Section: Applications/Multimedia
    Installed Size: 2400
    Maintainer: kde-redhat Developers <http://kde-redhat.sf.net/>
    Version: 0:0.4.3-0.0.b.2
    Pre-Depends: rpmlib(CompressedFileNames) (<= 3.0.4-1),
    rpmlib(PartialHardlinkSets) (<= 4.0.4-1),
    rpmlib(PayloadFilesHavePrefix) (<= 4.0-1),
    rpmlib(VersionedDependencies) (<= 3.0.3-1)
    Depends: kdelibs (>= 6:3.2), libDCOP.so.4, libICE.so.6,
    libSM.so.6, libX11.so.6, libXext.so.6, libXrender.so.1,
    libXtst.so.6, libXv.so.1, libc.so.6, libc.so.6(GLIBC_2.0),
    libc.so.6(GLIBC_2.1.3), libdl.so.2, libgcc_s.so.1,
    libkdecore.so.4, libkdefx.so.4, libkdeprint.so.4,
    libkdesu.so.4, libkdeui.so.4, libkio.so.4,
    libkparts.so.2, libm.so.6, libm.so.6(GLIBC_2.0),
    libnsl.so.1, libpng12.so.0, libpthread.so.0,
    libpthread.so.0(GLIBC_2.0), libqt-mt.so.3, libresolv.so.2,
    libselinux.so.1, libstdc++.so.5, libstdc++.so.5(CXXABI_1.2),
    libstdc++.so.5(GLIBCPP_3.2), libutil.so.1, libxine.so.1,
    libz.so.1, qt (>= 1:3.3)
    Provides: libkaffeinepart.so, kaffeine (= 0:0.4.3-0.0.b.2)
    Obsoletes: kaffeine-plugin (< 0:0.4.3)
    Architecture: i386
    Size: 1
    MD5Sum:
    Filename:
    Description: A xine-based Media Player for KDE
     Kaffeine is a xine based media player for KDE3. It plays back CDs,
     DVDs, and VCDs. It also decodes multimedia files like AVI, MOV, WMV,
     and MP3 from local disk drives, and displays multimedia streamed over
     the Internet. It interprets many of the most common multimedia formats
     available - and some of the most uncommon formats, too. Additionally,
     Kaffeine is fully integrated in KDE3, it supports Drag and Drop and
     provides an editable playlist, a bookmark system, OSD and much more.

Ok, ignore the stuf about the dependencies and concentrate on the description. That's what I said I wanted right? Then I should install it.

The graphic way

There are several graphic frontends for APT. The one I am more familiar with is synaptic.

You can install it from the command line:

    apt-get install synaptic

And just use it. It is supposed to be intuitive, so that's all I'm gonna say about it.

Conflicts

What's a conflict? Imagine package A requires library L version 1. And Package B requires library L version 2, and you can't have both versions installed.

If your repositories contain A, B, L1 and L2, when you install B, if you had A already installed, APT will remove A and L1. It will ask you first, so you should really read carefully whenever APT tells you that it will remove packages.

In any case, it's not so terrible, because you can always just install A again, which will remove B and L2 ;-)

There are some other forms of conflict, and some other ways that APT can fail. For example, if you once installed a package without its dependencies by using the --nodeps switch for RPM (you shouldn't), APT will not like it.

If you have two versions of the same program installed, APT will not like it.

APT Repositories

Your APT is only as good as your repositories. If you have a lame set of repos, your APT is an ignorant tool that only knows how to install xbill.

Ok, it's somewhat better than that, since the APT package freshrpms provides includes a set of repositories already set for you. But that's just the beginning.

Picking up repos

You can add a repository in the /etc/apt/sources.list file, but I don't recommend it. A better idea is this:

For each diferent repository you want to use, create a file in /etc/apt/sources.list.d. For example, to use the DAG repository, I would create /etc/apt/sources.list.d/dag.list (the .list extension is required).

Later, if I want to stop using it, I can just rename it something else, or even delete the file. And that way, you don't have to edit a single file with a lot of garbage.

But what goes in that file?

Source lines. Here's an example (my dag.list file, in fact):

    # Dag RPM Repository for Fedora Core 2
    rpm http://apt.sw.be fedora/2/en/i386 dag

The line starting with # is a comment, so no biggie. The second line is the important thing.

RPM means this line is about RPM packages (as opposite to a rpm-src line, for example)
http://apt.sw.be is the webserver holding the repository
fedora/2/en/i386 is the directory inside the server that contains packages for your distro (Fedora core 2 in this case)
dag is the repository to be used. Some servers contain several repositories. In those cases you can use several lines (one for each), or you can put several in the same line, for example:

    rpm http://ayo.freshrpms.net fedora/linux/2/i386 core updates freshrpms

That uses the core updates and freshrpms repositories from the same server. Often, a repository will have separate repositories for stable and unstable software, or for base system and extras, or for base and updates. It varies from server to server.

Notice how the path and repository names are different in the two examples. That is because it's a function of where the RPMs are stored in the server, you can't just make up any stuff you want.

To put it simply: you need to find, for each repository you want to use, what the source lines are.

Normally, that means a visit to the repository's website, and look around a little. Be very careful to use the repository matching your distro, or weird stuff may happen. Like, say, upgrading your distro from Mandrake 10.1 to Red Hat 7.3 ;-)

Some repos for you

So, here's some nice repositories you can try. Using these repositories should not cause conflicts.

These are also cool, but they may cause conflicts more often than limiting yourself to the first set.

Final words

Hope you enjoyed the article. If you did, there's more in the Articles section of the site.

If you have any doubt or question about any of this, just post a comment or email me. The best thing is probably to post a comment and email me telling me you posted it

Did you like the heavy linking in this article? Let me know so I can figure out if I will do it again.