[vox-tech] mixing potato and woody entries in apt sources.list
vox-tech@lists.lugod.org
vox-tech@lists.lugod.org
Tue, 18 Jun 2002 17:24:39 -0400
On Wed, Jun 12, 2002 at 06:00:18PM -0700, Doug Huckaba wrote:
> When I did I commented out the security.debian.org
> entries in sources.list because the lines referenced potato.
Doug,
At the time there was no security archive, I think because the security
team only follows released (or soon to be released) debian versions...
sid and testing have had limited coverage. I vaguely recall reading
something where that was to change, and don't know if all three releases
now get covered by the security group.
There is now a woody secrurity archive available, so you can now add
the following to your sources.list:
deb http://security.debian.org woody/updates main contrib non-free
> Will uncommenting these lines cause problems?
No.
> What I'm wondering is if
> there is a package released in the woody tree (please correct me if I get
> the terms wrong) and then a different version released from the security
> site, which would take precedence?
Based on observation apt will grab the highest version and highest
revision of any packages being install or updated... when a security
patch is done it bumps the revision number not the version number.
What this means is if a newer upstream version of a package was included
in woody then the security fixes for older potato packages would be silently
ignored. Which is what you want.
You may have noticed that debian package names look something like:
pool/main/v/vim/vim_6.1.018-1_i386.deb
^^^ ^^^^^^^ ^ ^^^^
vim = package name
6.1.0018 = upstream version number
1 = debian package revision
i386 = architecture
> for example: application-1.0 is installed from potato, then the woody
> dist-upgrade installs application-2.0, then application 1.5 is 'released'
> from the security site for potato. Which is the last version installed? or
> does this even happen?
As I mentioned above... "1.5" would not be released by the security
team. "1.0-1" would have been the flawed package and the security
team would release "1.0-2". But for the purposes of this example
even if they did release "1.5-1" it would still not be selected because
"2.0-1" is a higher version.
For what it's worth you can have both each of testing and unstable
both in your sources.list file, and with the use of /etc/apt/preferences
have the apt command set default to testing, but on the command line when
doing an install you can request the package from unstable... this will
be handy for things like pulling just mozilla 1.0 or X 4.2 from unstable
when it becomes available there...
There is risk: a package in unstable _could_ create a dependency
arch that in effect pulls the core of unstable onto your system.
This is a hypothetical example and hopefully does not match current
reality:
If for example mozilla as a dependency required the sid version of
glibc, and a bunch of other packages in woody 'require' the testing
version of glibc, but the two versions of glibc conflict... then a
whole bunch of woody packages would also upgrade to sid versions.
Care should be exercised... because this type of thing could happen
any time you do a upgrade, not just when installing a single package.
There is some good documentation available about this stuff in the
following man pages:
apt-get(8)
apt_preferences(5)
interesting portions of those man pages are at the bottom of this email.
I have not used preferences to pin a version before... so I don't have
syntax examples to paste. I've tacked it onto my list of things to try out,
so I might follow up this post [much] later with samples.
What I normally do is one of two things: temporarily add unstable to the
sources.list, "apt-get install" the package I want from unstable
(paying attention to what else will be pulled down by this), then comment
out the unstable source list. Until testing gets that version or newer
of the package it will not be replaced.
If I see that installing the package will pull down too many other
components, then I switch to deb-src lines for unstable, pull the
source with "apt-get source", and build a deb with dpkg-buildpackage.
The advantage of this method is the package built this way will have
dependencies for other files that match the packages installed on the
system at build time, via things like this you can build a modern perl
5.6 .deb for potato.
Later,
Mike
apt-get:
# install
# install is followed by one or more packages desired
# for installation. Each package is a package name,
# not a fully qualified filename (for instance, in a
# Debian GNU/Linux system, libc6 would be the argu-
# ment provided, not em(libc6_1.9.6-2.deb)). All
# packages required by the package(s) specified for
# installation will also be retrieved and installed.
# The /etc/apt/sources.list file is used to locate
# the desired packages. If a hyphen is appended to
# the package name (with no intervening space), the
# identified package will be removed if it is
# installed. Similarly a plus sign can be used to
# designate a package to install. These latter fea-
# tures may be used to override decisions made by
# apt-get's conflict resolution system.
#
# A specific version of a package can be selected for
# installation by following the package name with an
# equals and the version of the package to select.
# This will cause that version to be located and
# selected for install. Alternatively a specific dis-
# tribution can be selected by following the package
# name with a slash and the version of the distribu-
# tion or the Archive name (stable, frozen, unsta-
# ble).
#
# Both of the version selection mechanisms can down-
# grade packages and must be used with care.
#
# If no package matches the given expression and the
# expression contains one of '.', '?' or '*' then it
# is assumed to be a POSIX regex and it is applied to
# all package names in the database. Any matches are
# then installed (or removed). Note that matching is
# done by substring so 'lo.*' matches 'how-lo' and
# 'lowest'. If this is undesired prefix with a '^'
# character.
apt_preferences:
#DESCRIPTION
# The APT preferences file controls various aspects of the
# APT system. It is meant to be user editable and manipu-
# latable from software. The file consists of a number of
# records formed like the dpkg status file, space seperated
# sections of text with at the start of each line tags
# seperated by a colon. It is stored in /etc/apt/prefer-
# ences.
#
#VERSIONING
# One purpose of the preferences file is to let the user
# select which version of a package will be installed. This
# selection can be made in a number of ways that fall into
# three categories, version, release and origin.
#
# Selection by version can be done by exact match or prefix
# match. The format is 2.1.2 or 2.2* for a prefix match.
# Matching by prefix can be used to ignore the r in the
# Debian release versioning, like 2.1r* or to ignore Debian
# specific revisions, 1.1-*. When matching versions with a
# prefix the highest matching version will always be picked.
#
# Selection by release is more complicated and has three
# forms. The primary purpose of release selections is to
# identify a set of packages that match a specific vendor,
# or release (ie Debian 2.1). The first two forms are short-
# cuts intended for quick command line use. If the first
# character of the specification is a digit then it is con-
# sidered to be a release version match, otherwise a release
# label match. Specifications which contain equals are full
# release data matches and are a comma seperated list of one
# letter keys followed by an equals then by the string.
dpkg also has a basic --compare-versions operation:
dpkg:
# dpkg --compare-versions ver1 op ver2
# Compare version numbers, where op is a binary oper-
# ator. dpkg returns success (zero result) if the
# specified condition is satisfied, and failure
# (nonzero result) otherwise. There are two groups
# of operators, which differ in how they treat a
# missing ver1 or ver2. These treat no version as
# earlier than any version: lt le eq ne ge gt. These
# treat no version as later than any version: lt-nl
# le-nl ge-nl gt-nl. These are provided only for
# compatibility with control file syntax: < << <= =
# >= >> >.