]>
Commit | Line | Data |
---|---|---|
b2e465d6 AL |
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> |