l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Jun 18 19:22

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] mixing potato and woody entries in apt sources.list
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] mixing potato and woody entries in apt sources.list

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.


  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?


> 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:
                ^^^ ^^^^^^^ ^ ^^^^
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 
  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:
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.


#       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.

#       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.
#       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 --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: < <<  <=  =
#              >= >> >.
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!