You are here

APT Configuration

Details on my APT setup, which has made my interactions with the Debian packaging system much more enjoyable.

  1. Approx, an easy-to-configure apt proxy.

    If you have more than one Debian system on the same physical network segment, you need an apt proxy. It will save you and your favorite Debian mirror bandwidth. One approx server can handle Debian, Ubuntu, GNUSense, and any other APT-using client OS. Even if you only have one system, approx rarely causes any problems or slowness and can make building Debian VMs or chroots much faster. There are other pieces of free software that provide apt-proxy services, but approx is the one I use and it can be configured by a drunken monkey.

    My Configuration, and its breakdown.

    Here's the configuration I'm using on rei, my primary VPS.

    $interface any
    $max_wait 10

    Repository Mappings

    Requests for names on the left are translated into request for URLs on the right. So, if an application requests http://rei:9999/debian/dists/lenny/Release, approx will check, update it's local copy if needed, and send the application the most up to date version. If it does have to pull a new version it will "tee" the data from the remote server to both the requesting application and the cache so there's no delay even if the cache is out of date.


    Prefix the parameter name with a $ so that approx doesn't interpret it as a repository mapping.

    The interface to which approx will bind. I use "lo" for approx instances that are only used by my VMs and chroots and "any" for approx instances that serve machines across a network.
    port (not shown above)
    The TCP port to which approx will bind. The default is 9999, which is what I use everywhere. You will generally need to know this so that you can write the correct URLs in your sources.list.
    If approx is already downloading a file for one application and another one requests the same file, it can't use the cache because it is still incomplete. This setting is how many seconds approx will wait for the first download to finish. If the download is not complete at that time, it will make a second request to the repository and stream that directly to the second application, bypassing the cache entirely.

    There are more, but I just use the defaults for those.

  2. See The World, sources.list

    This is the sources.list from rei. My desktop and laptop still need some non-free software for hardware support so they add contrib and non-free to the lines. I also use Debian-multimedia repositories for those, although I'm not sure if that software is free or not.

    deb     http://localhost:9999/debian    stable          main
    deb-src http://localhost:9999/debian    stable          main
    deb     http://localhost:9999/security  stable/updates  main
    deb-src http://localhost:9999/security  stable/updates  main
    deb     http://localhost:9999/volatile  stable/volatile main
    deb-src http://localhost:9999/volatile  stable/volatile main
    deb     http://localhost:9999/backports lenny-backports main
    deb-src http://localhost:9999/backports lenny-backports main
    deb     http://localhost:9999/debian    testing         main
    deb-src http://localhost:9999/debian    testing         main
    deb     http://localhost:9999/security  testing/updates main
    deb-src http://localhost:9999/security  testing/updates main
    deb     http://localhost:9999/debian    unstable        main
    deb-src http://localhost:9999/debian    unstable        main
    deb     http://localhost:9999/debian    experimental    main
    deb-src http://localhost:9999/debian    experimental    main

    Keep in mind that the URLs will change based on where you approx server is. Without other directions, this sources.list would upgrade much of your system to Debian unstable. That's not something I want to do even for my desktop, and I will get to "solving" that "problem" in the next section.

    A final word of caution, this will automatically roll to next version of stable when it is released, which was my goal. However, you may want to replace the aliases above with the more persistent codenames. I.e. stable -> lenny; testing -> squeeze; unstable -> sid at the time of this writing.

  3. APT Preferences, most stable please

    Again, this configuration comes from rei.

    Package: *
    Pin: release a=stable
    Pin-Priority: 900
    Package: *
    Pin: release a=lenny-backports
    Pin-Priority: 800
    Package: *
    Pin: release a=testing
    Pin-Priority: 700
    Package: *
    Pin: release a=unstable
    Pin-Priority: 500
    Package: *
    Pin: release a=experimental
    Pin-Priority: 300

    It seems like a lot of Debian users don't know about this file. When someone mentions "pinning" this is the file they are talking about. It is placed in /etc/apt/preferences but the man page is apt_preferences in section 5. It took me a few tries to get this to do what I wanted, but now I don't know how I ran Debian without it.

    I'll refer you to the man page for the specifics on Pin-Priority, especially for values outside the 100-1000 range, but basically when apt-get or aptitude is installing a package, it takes the one with the highest priority. If there are two candidates with the same priority, it takes the one with the highest version. So, the setup above gives the result that stable is used when possible, then falling back to backports, testing, unstable, and finally experimental in that order.

    When satisfying version-restricted dependencies or when the user specifies the version they want installed, that restriction applied before considering priorities. This way I can install any version Debian has in their repository if I want, but my the system stays as close to stable as dependencies will let it.

  4. Configuration

    I've modified a few things about my apt configuration, by adding files to /etc/apt/apt.conf.d


    In Etch, APT had an hard limit on how many package versions it would put into the APT cache, and the default was quite small. This meant large sources.list files like mine cause apt-get update or aptitude update to fail. You could add a line like APT::Cache-Limit "99999999"; to increase this hard limit. If an update failed, you'd just add another '9'.

    I'm not seeing this setting on my fresh Lenny installs, so perhaps the default has been raised or the hard limit has gone away.


    APT actually installs some cron jobs by default. The jobs run, but don't do (much of) anything until you actually configure them.

    APT::Periodic {
            Update-Package-Lists            1;
            Download-Upgradeable-Packages   1;
            AutocleanInterval               7;

    This will automatically do an "update" operation every day. After that "update" it will also download (but not install) packages that are eligible for an upgrade; you won't have to wait on them to download one you do the install manually. Finally, downloaded packages that are older that a week get deleted.

    Controlling Dependencies

    These settings might not be for everyone, but they suit me well. I like a lot of control over what packages are installed, but I also like being about to keep packages as "automatically" installed because it eases upgrades.

    Aptitude {
            Recommends-Important    "false";
            Keep-Recommends         "true";
            Keep-Suggests           "true";

    First make aptitude not satisfy Recommends dependencies by default. Aptitude will still list recommendations and suggestions of the packages to be installed in the "preview" tab. You can still use the "Audit Recommendations" view to view recommendations of installed packages. Viewing suggestions of the installed packages is a minor alteration to the limit-view used by "Audit Recommendations".

    The last two make it to where an "automatically" installed package will not be removed until nothing depends on, recommends, or suggests it. This allows more of my packages that I only have installed to complement another package (e.g. suggestions) to be marked as "automatically" installed.