[vox-tech] mixing potato and woody entries in apt sources.list
Doug Huckaba
vox-tech@lists.lugod.org
Tue, 18 Jun 2002 19:30:14 -0700 (PDT)
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.
--
-doug
"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:
> #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: < << <= =
> # >= >> >.
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>