Adding Additional Software Repositories

Adding Additional Software Repositories

SUMMARY

Be careful when adding additional software to the Eee version of the Xandros OS. It is not considered compatible with Debian packages. Only use the Xandros 4 repositories for stability!

Xandros is a fork of Debian. The people at Xandros took the Debian distribution source code and recompiled it and tweaked it to suit their needs. As a result of the forking process Xandros is not considered to be Debian compatible. Downloading packages or adding the Debian software archives to the Xandros operating system will, eventually, break something important. The Eee version of Xandros is further modified, but it's closest blood relative is Xandros Desktop Edition 4 (Xandros 4). The safest way to keep your system stable is to only install packages that have been built for Xandros specifically.

The official word from Xandros is that adding Debian repositories will break Xandros. This is true in some instances and while a package may appear to install, it does not guarantee that it will run, or break your system. In order to add additional software to the Eee Xandros Distribution you will need to use Xandros packages… and the Xandros Networks (Xandros' name for a software repository) is only available to Xandros Desktop 4 and Xandros Server 4 customers…. which makes it very hard for us. Fortunately many Xandros users noticed this and started to build repositories of their own that were considered to be compatible with Xandros. Below is a link to a forum post in the Xandros Support Forums that lists a bunch of community repositories that you can add and download software from.

EDITOR NOTE: You can add the following lines to your /etc/apt/sources.list

Note: The Xandros repository is for the Server 2.0 which has the same base as the EeePC but with the KDE packages removed.

Note: Not all of the listed repositories have public keys available, so you may get warnings when installing packages from them.

deb http://xnv4.xandros.com/xs2.0/upkg-srv2 etch main contrib non-free deb http://dccamirror.xandros.com/dccri/ dccri-3.0 main deb http://www.archlug.org/apt/ xandros4 archlug xorid/andrew xorid/matty xorid/uploads deb http://www.geekconnection.org/ xandros4 main

Note: The www.archlug.org domain is not currently (12-Dec-2007) resolving correctly giving errors for these repositories.

The following is a community repository specifically for the EeePC. In the main section are packages that have been compiled specifically for the EeePC. In the etch section are packages that have been reported to work on the EeePC and have minimal unmet dependencies in the stock distro. Leave “etch” off the end of the line if you don't want access to these packages, but it is probably the safest way to add debian packages (no warranties, explicit or implied).

deb http://download.tuxfamily.org/eeepcrepos/ p701 main etch

NOTE: Not all sources listed in the forum link below are for Xandros 4. Some are for previous versions of Xandros. DO NOT USE THEM!

http://forums.xandros.com/viewtopic.php?t=22296

If you absolutely MUST use the Debian repositories for packages, consider user apt-pinning so that you don't hose your system.

If you choose to take the risk to use unsupported repositories you should use pinning.

Note: Xandros Server 2.0 is the closest to EeePC Xandros as it is the only other Xandros OS that is based on Debian Etch; however, it has a lower version of KDE than Debian Etch uses, therefore all KDE apps from the apt repo will not work.

PINNING YOUR SYSTEM

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 achieve this we pin our system by adding following lines to /etc/apt/preferences (if it does not exist, create it).

Package: * Pin: origin update.eeepc.asus.com Pin-Priority: 950 Package: * Pin: origin Pin-Priority: 925 Package: * Pin: origin xnv4.xandros.com Pin-Priority: 900 Package: * Pin: origin dccamirror.xandros.com Pin-Priority: 850 Package: * Pin: origin www.archlug.org Pin-Priority: 800 Package: * Pin: origin www.geekconnection.org Pin-Priority: 750 Package: * Pin: release a=stable Pin-Priority: 700 Package: * Pin: release a=testing Pin-Priority: 650 Package: * Pin: release a=unstable Pin-Priority: 600

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 is to give the Asus Eee PC repositories priority to protect important base system packages.
Second entry gives local repositories (CD, HD, USB memory etc.) the next highest priority (925). 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
Third and fourth entry gives Xandros supported and unsupported sites second highest priority (900 and 850). 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.
Fifth entry gives archlug repositories a priority of 800.
Sixth entry gives geekconnection repositories a priority of 750.
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.

OVERRIDING PINNING

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 instead:

 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.

Pinning gives specific repositories priority so that a package available from Xandros will never be overwritten by a Debian package, even if the Debian package is newer. This is especially important for libraries. Say you have official Asus package A using official Asus lib B. You install Debian package C which requires the same library of higher version number B1. You apt-get install and B gets overwritten with B1. Now you launch program A which uses library B but library B is now different and say the developers dropped support for something. A problem like this could even happen just by adding mixed repositories and doing an apt-get upgrade.

My suggestion is that you set up your repositories with official Asus at highest priority and Xandros desktop 4 at second. if you absolutely need something not available add Debian etch as 3rd priority, but beware there is still some risk.

RECOVERING FROM AN 'OOPS'

Occasionally you may find that despite your best intention and careful planning, and the use of pinning, you install a version of a package that breaks your system. One likely one: upgrading your version of kdebase-data from the version in the Asus repository (3.4.2.201 as of Nov 21, 2007) to a newer version available in the Debian repository (3.5.5 as of the same date) will cause the Control Centre to stop functioning correctly. In Easy Mode, you'll find that your Date & Time configurator in the Settings tab no longer works (and you'll get an error if you invoke it from a Terminal as 'kcmshell clock'), neither does your Network configurator in the Internet Tab (though Wireless Networks still works), nor Mozilla Thunderbird (which appears as Mail in the Work tab), that Control Centre has no modules to control (open it with 'kcontrol' in a Terminl in Easy Mode, or by running the Control Centre app in Advanced Mode), and that you can no longer open a Terminal window by pressing Ctrl-Alt-T… and there may be other effects as well. What you need to do in this case is downgrade your package.

Open File Manager and navigate to /var/cache/apt/archives. This is where all the downloaded packages are stored as .deb files (and where you should store any stray .deb files that you install on your system).
Scan the list of packages and look to see which versions are most common, particularly for anything related to KDE. For example, notice that many of the KDE-related packages have version 3.4.2. For confirmation, locate the Asus repository in the list above and visit that repository with your web browser. Again, look for typical version numbers.
Identify the offending package by noting that it has a different version number, or by its effects. In the case of a package like kcontrol, we've already seen that the wrong version can have a whole host of negative effects.
Determine which version you should downgrade to. One simple way to do this is to find out the history of which versions of the package have been installed on your system. To do this, open a Terminal and type:

 apt-cache policy <package-name>

Now downgrade the package by explicitly installing a lower version number, which you specify by adding an = after the package name and then the version number desired. For example:

 sudo apt-get install kdebase-data=4:3.4.2.201-1

If that worked, count yourself lucky. If it didn't fix all your problems, go looking for other packages to downgrade. Worst-case scenario: simply restore the base Asus installation.
In the future, never just blindly 'apt-get install <package-name>. Always take the precaution of doing a dry-run to see what will happen in the installation; do this by adding the -s argument after the apt-get: