Skip to content

Pinning mit Xandros / Debian

Quite often people want to be able to install applications from other repositories than those provided by Xandros. To minimize the risk to break something by accident (breaking by force is hard to prevent) in such mixed system, Debian (upon which Xandros is based on) provides a function called pinning.

While the basics of pinning is described in the link below, this HOWTO shows how to use pinning in Xandros.

Furthermore, use the apt-get command directly from a console rather than using XN. Its faster, safer and gives you more options to control the installation process. Whish Xandros would add more of that stuff to XN. As long as you plan to stick to Xandros sites, you can still use XN successfully with suggested pinning.

This HOWTO applies both to X2 and X3 and is intended to give some basic settings. More advanced features can be found in the link above (e.g. how to setup own repositories with release files).

CONFIGURING /etc/apt/sorces.list

Contains all repositories to include in search for packages. It is explained in following link.

You may want to add following repositories from Debian.

deb stable main contrib non-free
deb testing main contrib non-free
deb unstable main contrib non-free

Mirror sites can be found here.

CONFIGURING /etc/apt/apt.conf

This file controls the behaviour of the APT system. Its not much that need to be configured in here. But following items can be good to know.

APT::Cache-Limit 10000000;

If you ever get a message like the one below, this item is the problem (the cache is too small). It may occur if you have enabled a couple of large repositories. In such case, just increase this value.

E: Dynamic MMap ran out of room

APT::Default-Release "xandros";

This one is not necessary since Xandros currently does not provide their own release archive name (which they should in my opinion).

For more items, take a look in the man page for apt-get and /usr/share/doc/apt/examples/apt.conf.


When having multiple repositories it's not unusual that same package exists in more than one of those repositories, but with different version numbers. The default behaviour in an unpinned system is to install the one with the highest version number.

When mixing Xandros with repositories from other sites this is not the behaviour we want. Instead, what we want is to always install packages from Xandros repositories no matter what version they have and only if packages do not exist in Xandros repositories or we explicitly says so shall packages be installed from other repositories.

To achive this we pin our system by adding following lines to /etc/apt/preferences (if it does not exist, create it).

Pin: origin
Pin-Priority: 999


Pin: origin
Pin-Priority: 888

Pin: release a=testing
Pin-Priority: 666


Pin: release a=stable
Pin-Priority: 777

Package: *
Pin: release a=unstable
Pin-Priority: 555

Pinning gives various sources different priorities. Sources are recognized by their release information (requires a release file), origin or version number. In the above example we only use origin and release archive (release a=xxx) as identifiers.

This is what the pinning above does:

- First entry gives local repositories (CD, HD, USB memory etc.) highest priority (999). Those are recognized as being from an unknown origin (an empty string). It is possible to assign local repositories their own release files, which pinning can be based on. But that is out of scope for this discussion and not realy necessary

- Second entry gives Xandros supported and unsupported sites second highest priority (888). Those are pinned on the origin rather than release archive since Xandros does not provide proper release files. It's fine to have supported and unsupported at same priority since no package exists in both repositories simultaneously.

- The remaining entries are for download from Debian.

- Repositories not mentioned will have priority 500.

- Repositories with release archive name APT::Default-Release will have priority 990. We don't use this. We will however later on show how one can temporary assign an APT::Default-Release to a system to override the pinning.

If you add Xandros, Debian plus some local repositories you can use apt-cache policy to see the priority order.


Imagine we want to download firestarter firewall. Xandros repositories has version 0.9.3 while Debian has version 1.0.1. With the pinning in previous chapter, if we execute

apt-get install firestarter

version 0.9.3 will be installed. If we instead wanted to download the Debian version we had to execute the command below instead.

apt-get install firestarter/testing

This tells the APT system that firestarter shall be downloaded from the source with the release archive name testing and therby override the pinning for that particular package. Any libraries firestarter depends on will still be downloaded from Xandros repositories. If firestarter depends on versions of libraries not present in Xandros, installation will fail.

The solution to this is to execute following command in stead.

apt-get -t testing install firestarter

This tells the APT system to change our APT::Default-Release temporary to testing and thereby giving Debian testing repository priority 990. With the pinning in previous chapter this means firestarter and all its libraries will be downloaded from the Debian repository instead of Xandros.


It is possible to downgrade packages as well. Assume we have installed firestarter v1.0.1 as described in previous chapter and now we have changed our mind and want to revert to v0.9.3 instead. To do this, we change the priority of Xandros sites from 888 to a value greater than 1000 (e.g. 1002) and executes

apt-get install firestarter


I mentioned previously I prefer using APT command line tools rather than XN. Here is one example how to use them:

1. apt-get update
2. apt-get -s install
3. If 2 seem OK, proceed to 4.
4. apt-get --no-remove install
5. If 4 fails, analyze the problem and if removal of packages seem OK do 4 again without --no-remove.

In 2 , we test what would happen if we installs a package without actually upating our system. If it looks suspicious, don't install the package.

In 4, we just add another level of protection while installing. If something will be removed as a consequence of the install, we want to abort the installation to analyze the problem (in my experience, package removal is the most common problem why system breaks).

Use man pages for more detailed description of each command.

apt-get update

The very first command to execute after any change in sources.list. In fact, it may be good idea to execute it from time to time even if sources.list has not changed since packages may have been added or removed from repositorise since last time.

apt-cache search

Search for package and/or package content

apt-cache show

Show package dscription

apt-get dist-upgrade

Does what XN update does

apt-get -s dist-upgrade
apt-get -s remove
apt-get -s install

Simulate an upgrade, remove or install.

apt-get -u dist-upgrade
apt-get -u install

Shows the complete list of packages which will be upgraded.

apt-get -o Debug::pkgProblemResolver=yes dist-upgrade
apt-get -o Debug::pkgProblemResolver=yes install

To know what's keeping or removing a package.

apt-get --no-remove dist-upgrade
apt-get --no-remove install

Install packages, but do not remove any as a consequence of that.

apt-get -d --reinstall install

Download packages, but don't install. Files are found under /var/cache/apt/archives.

apt-get clean

Deletes all in /var/cache/apt/archives (not done automatically unless explicitly configured to do so).

Another strategy is to perform:

dpkg --get-selections > myPackages.txt

before any package install. In case something goes wrong you can always reverse the process by applying

dpkg --set-selections < myPackages.txt
apt-get update
apt-get dselect-upgrade

this however only remove and installs packages as needed to fulfill the package state described in "myPackages.txt". It does not do any downgrade of package versions to my knowledge. For that you may need to follow the instructions here (its actually not complete, but a good start)

What I mean with downgrading is follow. A package A is mentioned in "myPackages.txt". You do install a package, which upgrades A to a newver version. Applying the commands above will not downgrade package A unless pinning is used.

The simplest way to see what happens is simply to try the commands for your self.