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 21:27

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

Thank you so much. That was the most coherent response to an e-mail I've 
received in about 6 months. That's not to say that receive poor responses 
on this list, I rarely post here as I usually learn more just from reading 
other responses. 


"In seeking wisdom thou art wise; in imagining that thou has attained it
thou art a fool." - Simon Ben Azzai, second-century Jewish scholar.

> 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:
> #       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:
> #       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
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

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:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.