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).
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 http://http.us.debian.org/debian stable main contrib non-free
deb http://http.us.debian.org/debian testing main contrib non-free
deb http://http.us.debian.org/debian unstable main contrib non-free
Mirror sites can be found here.
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.
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
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.
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 achive this we pin our system by adding following lines to /etc/apt/preferences (if it does not exist, create it).
Pin: origin xnv3.xandros.com
Pin: release a=testing
Pin: release a=stable
Pin: release a=unstable
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
OTHER TIPS AND TRICKS
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.
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.
Search for package and/or package content
Show package dscription
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.
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
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.