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.
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).
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.
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 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.
DOWNGRADING
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.
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.
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.
Edited by Arne Anka on Mon Jan 10, 2005 4:27 pm; edited 6 times in total
Edited by Rich Bacchetta on Sat April 16, 2005 7:31 AMOriginally posted by Arne Anka on Dec 28, 2004
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.
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).
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.
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 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.
DOWNGRADING
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.
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.
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.
Edited by Arne Anka on Mon Jan 10, 2005 4:27 pm; edited 6 times in total
Edited by Rich Bacchetta on Sat April 16, 2005 7:31 AM
