]> git.saurik.com Git - apt.git/blob - doc/apt_preferences.5.sgml
Join with aliencode
[apt.git] / doc / apt_preferences.5.sgml
1 <!-- -*- mode: sgml; mode: fold -*- -->
2 <!doctype refentry PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
3
4 <!ENTITY % aptent SYSTEM "apt.ent">
5 %aptent;
6
7 ]>
8
9 <refentry>
10 &apt-docinfo;
11
12 <refmeta>
13 <refentrytitle>apt_preferences</>
14 <manvolnum>5</>
15 </refmeta>
16
17 <!-- Man page title -->
18 <refnamediv>
19 <refname>apt_preferences</>
20 <refpurpose>Preference control file for APT</>
21 </refnamediv>
22
23 <RefSect1><Title>Description</>
24 <para>
25 The APT preferences file controls various aspects of the APT system.
26 It is ment to be user editable and manipulatable from software. The file
27 consists of a number of records formed like the dpkg status file, space
28 seperated sections of text with at the start of each line tags seperated
29 by a colon. It is stored in <filename>/etc/apt/preferences</>.
30 </RefSect1>
31
32 <RefSect1><Title>Versioning</>
33 <para>
34 One purpose of the preferences file is to let the user select which version
35 of a package will be installed. This selection can be made in a number of
36 ways that fall into three categories, version, release and origin.
37 <para>
38 Selection by version can be done by exact match or prefix match. The format
39 is <literal/2.1.2/ or <literal/2.2*/ for a prefix match. Matching by prefix
40 can be used to ignore the <literal/r/ in the Debian release versioning, like
41 <literal/2.1r*/ or to ignore Debian specific revisions, <literal/1.1-*/.
42 When matching versions with a prefix the highest matching version will
43 always be picked.
44 <para>
45 Selection by release is more complicated and has three forms. The primary
46 purpose of release selections is to identify a set of packages that match
47 a specific vendor, or release (ie Debian 2.1). The first two forms are
48 shortcuts intended for quick command line use. If the first character of the
49 specification is a digit then it is considered to be a release version match,
50 otherwise a release label match. Specifications which contain equals are
51 full release data matches and are a comma seperated list of one letter keys
52 followed by an equals then by the string. Examples:
53 <informalexample><programlisting>
54 v=2.1*,o=Debian,c=main
55 l=Debian
56 a=stable
57 </programlisting></informalexample>
58 <para>
59 The data for these matches are taken from the <filename/Release/ files
60 that APT downloads during an <literal/update/. The available keys are:
61 <VariableList>
62 <VarListEntry><term>a= Archive</term>
63 <ListItem><Para>
64 This is the common name we give our archives, such as <literal/stable/ or
65 <literal/unstable/. The special name <literal/now/ is used to designate
66 the set of packages that are currently installed.
67 </VarListEntry>
68
69 <VarListEntry><term>c= Component</term>
70 <ListItem><Para>
71 Referes to the sub-component of the archive, <literal/main/,
72 <literal/contrib/ etc. Component may be omitted if there are no
73 components for this archive.
74 </VarListEntry>
75
76 <VarListEntry><term>v= Version</term>
77 <ListItem><Para>
78 This is a version string with the same properties as in the Packages file.
79 It represents the release level of the archive. Typical Debian release
80 numbers look like <literal/2.1r2/ with the r designating the release of
81 2.1. New releases are limited to security updates.
82 </VarListEntry>
83
84 <VarListEntry><term>o= Origin</term>
85 <ListItem><Para>
86 This specifies who is providing this archive. In the case of Debian the
87 string will read <literal/Debian/. Other providers may use their own
88 string.
89 </VarListEntry>
90
91 <VarListEntry><term><term>l= Label</term>
92 <ListItem><Para>
93 This carries the encompassing name of the distribution. For Debian proper
94 this field reads <literal/Debian/. For derived distributions it should
95 contain their proper name.
96 </VarListEntry>
97 </VariableList>
98 <para>
99 The final selection method is by origin. This is simply the site name
100 of the originating package files. The empty string is used for file URIs.
101 <para>
102 Version selection, particularly the latter two methods, are used in may
103 different part of APT, not just the preferences file.
104 </RefSect1>
105
106 <RefSect1><Title>Candidate Version Policy</>
107 <para>
108 Interaly APT maintains a list of all available versions for all packages.
109 If you place multiple releases or vendors in your &sources-list; file then
110 these features are available. By default APT selects the highest version
111 from all automatic sources. Some sources, such as
112 <filename>project/experimental</> are marked Not Automatic - these fall
113 to the bottom of the selection pile.
114 <para>
115 When deciding what version to use APT assigns a priority to each available
116 version of the package. It then does two things, first it selects
117 the highest priorty version that is newer than the installed version of the
118 package, then it selects the highest priority version that is older than
119 the installed version. Next, if the older versions have a priority greater
120 than 1000 they are compared with the priority of the upgrade set, the larger
121 becomes the selected result. Otherwise the downgrade versions are ignored
122 and the highest priority of the ugprade set is selected.
123 <para>
124 It is possible to think of the priorities in strata:
125 <VariableList>
126 <VarListEntry><term>1000 and up</term>
127 <ListItem><Para>
128 Downgradable priorities
129 </VarListEntry>
130
131 <VarListEntry><term>1000</term>
132 <ListItem><Para>
133 The downgrade prevention barrier
134 </VarListEntry>
135
136 <VarListEntry><term>100 to 1000</term>
137 <ListItem><Para>
138 Standard priorities. 990 is the priority set by the
139 <option/--target-release / &apt-get; option. 989 is the start for auto
140 priorities and 500 are all the default package files.
141 </VarListEntry>
142
143 <VarListEntry><term>100</term>
144 <ListItem><Para>
145 The currently installed version
146 </VarListEntry>
147
148 <VarListEntry><term>0 to 100</term>
149 <ListItem><Para>
150 Non automatic priorities. These are only used if the package
151 is not installed and there is no other version available.
152 </VarListEntry>
153
154 <VarListEntry><term>less than 0</term>
155 <ListItem><Para>
156 The version is never selected.
157 </VarListEntry>
158 </VariableList>
159 <para>
160 Giving a pin a priority greater than 1000 will allow APT to downgrade
161 in order to get to that version.
162 <para>
163 Each package may be pinned to a specific version and each Package file
164 has a priority for every package inside. The highest priority assigned
165 to a package is the one that is used.
166 <para>
167 A package pin looks like this:
168 <informalexample><programlisting>
169 Package: apt
170 Pin: version 0.4.0
171 Pin-Priority: 1001
172 </programlisting></informalexample>
173 The first line specifies the package, the second gives the Pin specification
174 and the last gives the priority of this pin. The first word of the pin
175 specification may be version, release or origin, the remainder of the field
176 is described in the Versioning sectin above.
177 <para>
178 A default pin is how the priorities of package files are set. Any number
179 of default pins may be specified, the first matching default will select
180 the priority of the package file. Only release or origin may be used in
181 the Pin specification since they match Package files.
182 <informalexample><programlisting>
183 Package: *
184 Pin: release v=2.1*
185 Pin-Priority: 998
186 </programlisting></informalexample>
187 <para>
188 If the Pin-Priorty field is omitted then the priority defaults to 989 for
189 both cases.
190
191 <RefSect2><title>Interesting Effects</>
192 <para>
193 Due to the downgrade prevention barrier at priority 1000 it is possible
194 that a lower priority version will be selected if the higher priority
195 would casue a downgrade. For instance, if package foo has versions
196 <literal/1.2/, <literal/1.1/ and <literal/1.0/ installed, with
197 <literal/1.1/ being the currently installed version and the priorities of
198 each version being 900, 100 and 950 repectively the winning version will be
199 <literal/1.2/.
200 <para>
201 In practice this is often desired. A user may use a default pin to
202 make the stable distribution the default and then use the
203 <option/--target-dist/ option with &apt-get; to select newer versions
204 from unstable. The packages that have been upgraded to unstable will
205 continue to follow the versions that are available in unstable since
206 the stable versions now fall below the downgrade prevention barrier.
207 <para>
208 If this is not desired then a default pin should be used to make unstable
209 have a priority less than 100.
210 <para>
211 Users of 3rd party add ons such as Helix GNOME can use this mechanism to
212 force the usage of Helix packages, or force the usage of Debian packages
213 by setting the priority of that source sufficiently high. It is even
214 possible to mass downgrade from one set of packages to another by
215 using a priority larger than 1000.
216 </RefSect2>
217 </RefSect1>
218
219 <RefSect1><Title>See Also</>
220 <para>
221 &apt-cache; &apt-conf;
222 </RefSect1>
223
224 &manbugs;
225 &manauthor;
226
227 </refentry>