Re: Request for Review: APT manpages
And finally apt.conf.5.xml (I say finally, but this is another one
where I haven't produced a patch yet):
[...]
> <refsect1><title>Description</title>
> <para><filename>apt.conf</filename> is the main configuration file for
> the APT suite of tools, but by far not the only place changes to options
~~~~~~~~~~
> can be made. All tools therefore share the configuration files and also
~~~~~~~~~
> use a common command line parser to provide a uniform environment.</para>
Stylistically weird, and hard to follow. I suggest:
<filename>apt.conf</filename> is the main configuration file shared by all
the tools in the APT suite of tools, though it is by no means the only
place options can be set. The suite also shares a common command line
parser to provide a uniform environment.
> <orderedlist>
> <para>When an APT tool starts up it will read the configuration files
> in the following order:</para>
> <listitem><para>the file specified by the <envar>APT_CONFIG</envar>
> environment variable (if any)</para></listitem>
> <listitem><para>all files in <literal>Dir::Etc::Parts</literal> in
~~
Dir::Etc::Parts isn't a directory that literally contains files, so
say "listed in".
> alphanumeric ascending order which have either no or "<literal>conf</literal>"
Again, I don't like "no as filename extension".
The trouble with running this statement about collation straight into
the statements about which ones will be ignored is that you might be
saying that only the ones listed in the right order will be
considered!
> as filename extension and which only contain alphanumeric,
> hyphen (-), underscore (_) and period (.) characters.
> Otherwise APT will print a notice that it has ignored a file if the file
> doesn't match a pattern in the <literal>Dir::Ignore-Files-Silently</literal>
> configuration list - in this case it will be silently ignored.</para></listitem>
Too notty. Rephrase all this as:
<listitem>
<para>
all files listed in <literal>Dir::Etc::Parts</literal> in
alphanumeric ascending order. The filenames must have an extension of
"<literal>conf</literal>" or nothing, and may only contain
alphanumeric, hyphen (-), underscore (_) and period (.) characters;
otherwise APT will print a notice that it has ignored a file, unless
that file matches a pattern in the
<literal>Dir::Ignore-Files-Silently</literal> configuration list - in
this case it will be silently ignored.
</para>
</listitem>
> <listitem><para>the main configuration file specified by
> <literal>Dir::Etc::main</literal></para></listitem>
> <listitem><para>the command line options are applied to override the
> configuration directives or to load even more configuration files.</para></listitem>
> </orderedlist>
> </refsect1>
> <refsect1><title>Syntax</title>
> <para>The configuration file is organized in a tree with options organized into
> functional groups. Option specification is given with a double colon
> notation, for instance <literal>APT::Get::Assume-Yes</literal> is an option within
;
> the APT tool group, for the Get tool. Options do not inherit from their
> parent groups.</para>
>
> <para>Syntactically the configuration language is modeled after what the ISC tools
> such as bind and dhcp use. Lines starting with
(Did we decide the software was called BIND and DHCP?)
> <literal>//</literal> are treated as comments (ignored), as well as all text
> between <literal>/*</literal> and <literal>*/</literal>, just like C/C++ comments.
> Each line is of the form
> <literal>APT::Get::Assume-Yes "true";</literal>. The trailing
> semicolon and the quotes are required. The value must be on one line, and
Quotation marks may be officially correct, but it seems to tolerate
their absence...
> there is no kind of string concatenation. It must not include inside quotes.
By "inside" I assume it means "internal", but does "quotes" include
*single* quotes (AKA apostrophes)?
> The behavior of the backslash "\" and escaped characters inside a value is
> undefined and it should not be used. An option name may include
The behaviour is undefined and should not be used?
> alphanumerical characters and the "/-:._+" characters. A new scope can
> be opened with curly braces, like:</para>
I would suggest:
The quotation marks and trailing semicolon are required.
The value must be on one line, and there is no kind of string concatenation.
Values must not include backslashes or extra quotation marks.
Option names are made up of alphanumeric characters and the characters "/-:._+".
A new scope can be opened with curly braces, like this:</para>
> <informalexample><programlisting>
> APT {
> Get {
> Assume-Yes "true";
> Fix-Broken "true";
> };
> };
> </programlisting></informalexample>
>
> <para>with newlines placed to make it more readable. Lists can be created by
> opening a scope and including a single string enclosed in quotes followed by a
> semicolon. Multiple entries can be included, each separated by a semicolon.</para>
^^^^
It's the list that's semicolon-separated, not each member of the list.
semicolon. Multiple entries can be included, separated by semicolons.
> <informalexample><programlisting>
> DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt";};
> </programlisting></informalexample>
>
> <para>In general the sample configuration file in
> <filename>&docdir;examples/apt.conf</filename> &configureindex;
> is a good guide for how it should look.</para>
>
> <para>The names of the configuration items are not case-sensitive. So in the previous example
> you could use <literal>dpkg::pre-install-pkgs</literal>.</para>
It isn't text that's case-sensitive, it's things that parse text.
<para>
Case is not significant in names of configuration items, so in the
previous example you could use <literal>dpkg::pre-install-pkgs</literal>.
</para>
> <para>Names for the configuration items are optional if a list is defined as it can be see in
> the <literal>DPkg::Pre-Install-Pkgs</literal> example above. If you don't specify a name a
> new entry will simply add a new option to the list. If you specify a name you can override
> the option as every other option by reassigning a new value to the option.</para>
There are errors here that I can patch up:
s/as it can be see/as can be seen/
s/as every other option/in the same way as any other option/
but more importantly I don't understand what this is trying to say.
What is it that's being "omitted" in the DPkg::Pre-Install-Pkgs
example - that is, what would be present if they weren't omitted?
(Is it just that the values don't each need to be associated with a
different suboption name? If so it's making really heavy weather of
something utterly obvious...)
> <para>Two specials are allowed, <literal>#include</literal> (which is deprecated
> and not supported by alternative implementations) and <literal>#clear</literal>:
> <literal>#include</literal> will include the given file, unless the filename
> ends in a slash, then the whole directory is included.
They're both "allowed" in the sense that I shouldn't use the first
one...
Two special commands are defined: <literal>#include</literal> (which is
deprecated and not supported by alternative implementations) and
<literal>#clear</literal>. <literal>#include</literal> will include the
given file, unless the filename ends in a slash, in which case the whole
directory is included.
> <literal>#clear</literal> is used to erase a part of the configuration tree. The
> specified element and all its descendants are erased.
> (Note that these lines also need to end with a semicolon.)</para>
>
> <para>The #clear command is the only way to delete a list or a complete scope.
> Reopening a scope or the ::-style described below will <emphasis>not</emphasis>
> override previously written entries. Only options can be overridden by addressing a new
> value to it - lists and scopes can't be overridden, only cleared.</para>
"Only options"? Broken scope, and broken number agreement.
<para>
The <literal>#clear</literal> command is the only way to delete a list or
a complete scope. Reopening a scope (or using the syntax described below
with an appended <literal>::</literal>) will <emphasis>not</emphasis>
override previously written entries. Options can only be overridden by
addressing a new value to them - lists and scopes can't be overridden,
only cleared.
</para>
> <para>All of the APT tools take a -o option which allows an arbitrary configuration
an
> directive to be specified on the command line. The syntax is a full option
> name (<literal>APT::Get::Assume-Yes</literal> for instance) followed by an equals
> sign then the new value of the option. To append a new element to a list, add a
> trailing :: to the name of the list. (As you might suspect: The scope syntax can't
<literal>::</literal> ,
> be used on the command line.)</para>
>
> <para>Note that you can use :: only for appending one item per line to a list and
> that you should not use it in combination with the scope syntax.
> (The scope syntax implicit insert ::) Using both syntaxes together will trigger a bug
> which some users unfortunately depend on: An option with the unusual name "<literal>::</literal>"
> which acts like every other option with a name. These introduces many problems
> including that a user who writes multiple lines in this <emphasis>wrong</emphasis> syntax in
> the hope to append to a list will gain the opposite as only the last assignment for this option
> "<literal>::</literal>" will be used. Upcoming APT versions will raise errors and
> will stop working if they encounter this misuse, so please correct such statements now
> as long as APT doesn't complain explicit about them.</para>
> </refsect1>
<para>
Note that appending items to a list using <literal>::</literal> only works
for one item per line, and that you should not use it in combination with
the scope syntax (which adds <literal>::</literal> implicitly). Using both
syntaxes together will trigger a bug which some users unfortunately depend
on: an option with the unusual name "<literal>::</literal>" which acts
like every other option with a name. This introduces many problems; for
one thing, users who write multiple lines in this
<emphasis>wrong</emphasis> syntax in the hope of appending to a list will
achieve the opposite, as only the last assignment for this option
"<literal>::</literal>" will be used. Future versions of APT will raise
errors and stop working if they encounter this misuse, so please correct
such statements now while APT doesn't explicitly complain about them.
</para>
[...]
> <varlistentry><term><option>Architectures</option></term>
> <listitem><para>All Architectures the system supports. Processors implementing the
> <literal>amd64</literal> (also called <literal>x86-64</literal>) instruction set are
> e.g. also able to execute binaries compiled for the <literal>i386</literal>
> (<literal>x86</literal>) instruction set; This list is use when fetching files and
> parsing package lists. The internal default is always the native architecture (<literal>APT::Architecture</literal>)
> and all foreign architectures it can retrieve by calling <command>dpkg --print-foreign-architectures</command>.
> </para></listitem>
> </varlistentry>
Misplaced "e.g.", misspelled "used". What's an "internal" default?
And how does the --print-foreign-architectures part fit in?
[Goes away hunting end-user docs for multiarch... much later:]
Oh, it's saying that architectures that have been registered via
"dpkg --add-architecture" (which are bewilderingly known as "foreign"
architectures, even though the point is that you're acknowledging them
as functionally compatible) get added to the Architectures list?
I would tentatively suggest expressing that as:
<listitem>
<para>
All Architectures the system supports. For instance, CPUs implementing
the <literal>amd64</literal> (also called <literal>x86-64</literal>)
instruction set are also able to execute binaries compiled for the
<literal>i386</literal> (<literal>x86</literal>) instruction set. This
list is used when fetching files and parsing package lists. The
initial default is always the system's native architecture
(<literal>APT::Architecture</literal>), and foreign architectures are
added to the list when they are registered via
<command>dpkg --add-architecture</command>.
</para>
</listitem>
> <varlistentry><term><option>Default-Release</option></term>
> <listitem><para>Default release to install packages from if more than one
> version available. Contains release name, codename or release version. Examples: 'stable', 'testing',
^is
> 'unstable', '&stable-codename;', '&testing-codename;', '4.0', '5.0*'. See also &apt-preferences;.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Ignore-Hold</option></term>
> <listitem><para>Ignore Held packages; This global option causes the problem resolver to
h t
> ignore held packages in its decision making.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Clean-Installed</option></term>
> <listitem><para>Defaults to on. When turned on the autoclean feature will remove any packages
> which can no longer be downloaded from the cache. If turned off then
> packages that are locally installed are also excluded from cleaning - but
> note that APT provides no direct means to reinstall them.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Immediate-Configure</option></term>
Oh, this following paragraph is such a mess:
> <listitem><para>Defaults to on which will cause APT to install essential and important packages
Is it really "Essential: yes" and "Priority: important" packages but
not "Priority: required" ones?
> as fast as possible in the install/upgrade operation. This is done to limit the effect of a failing
"Soon", not "fast", unless it decrements a "sleep $DELAY" variable.
> &dpkg; call: If this option is disabled APT does treat an important package in the same way as
> an extra package: Between the unpacking of the important package A and his configuration can then
"His" configuration?
> be many other unpack or configuration calls, e.g. for package B which has no relation to A, but
> causes the dpkg call to fail (e.g. because maintainer script of package B generates an error) which results
> in a system state in which package A is unpacked but unconfigured - each package depending on A is now no
> longer guaranteed to work as their dependency on A is not longer satisfied. The immediate configuration marker
> is also applied to all dependencies which can generate a problem if the dependencies e.g. form a circle
When it says "e.g." here, what *other* kinds of problematic
dependency besides circular ones is it choosing not to mention?
> as a dependency with the immediate flag is comparable with a Pre-Dependency. So in theory it is possible
> that APT encounters a situation in which it is unable to perform immediate configuration, errors out and
> refers to this option so the user can deactivate the immediate configuration temporarily to be able to perform
It's not clear what's going on in this (theoretical) example. Is the
idea that Immediate-Configure allows APT to *recognise* the problem,
abort, and ask for advice instead of blindly running into worse
trouble? Does "refers to this option" mean that there's a dialogue
suggesting that it should be temporarily deactivated?
> an install/upgrade again. Note the use of the word "theory" here as this problem was only encountered by now
> in real world a few times in non-stable distribution versions and was caused by wrong dependencies of the package
> in question or by a system in an already broken state, so you should not blindly disable this option as
> the mentioned scenario above is not the only problem immediate configuration can help to prevent in the first place.
> Before a big operation like <literal>dist-upgrade</literal> is run with this option disabled it should be tried to
^^^^^^^^^^^^^^^^^^^^^
This use of an impersonal verb doesn't work, and is unnecessary when
the rest of the paragraph (and sentence) addresses "you" directly.
> explicitly <literal>install</literal> the package APT is unable to configure immediately, but please make sure to
> report your problem also to your distribution and to the APT team with the buglink below so they can work on
> improving or correcting the upgrade process.</para></listitem>
> </varlistentry>
<listitem>
<para>
Defaults to on, which will cause APT to install essential and important
packages as soon as possible in an install/upgrade operation, in order
to limit the effect of a failing &dpkg; call. If this option is
disabled, APT treats an important package in the same way as an extra
package: between the unpacking of the package A and its configuration
there can be many other unpack or configuration calls for other
unrelated packages B, C etc. If these cause the &dpkg; call to fail
(e.g. because package B's maintainer scripts generate an error), this
results in a system state in which package A is unpacked but
unconfigured - so any package depending on A is now no longer
guaranteed to work, as its dependency on A is no longer satisfied.
Optionally, insert </para><para> here.
The immediate configuration marker is also applied in the potentially
problematic case of circular dependencies, since a dependency with the
immediate flag is equivalent to a Pre-Dependency. In theory this allows
APT to recognise a situation in which it is unable to perform immediate
configuration, abort, and suggest to the user that the option should be
temporarily deactivated in order to allow the operation to proceed.
Note the use of the word "theory" here; in the real world this problem
has rarely been encountered, in non-stable distribution versions, and
was caused by wrong dependencies of the package in question or by a
system in an already broken state; so you should not blindly disable
this option, as the scenario mentioned above is not the only problem it
can help to prevent in the first place.
Again, optional </para><para>.
Before a big operation like <literal>dist-upgrade</literal> is run
with this option disabled you should try to explicitly
<literal>install</literal> the package APT is unable to configure
immediately; but please make sure you also report your problem to your
distribution and to the APT team with the buglink below, so they can
work on improving or correcting the upgrade process.
</para>
</listitem>
</varlistentry>
> <varlistentry><term><option>Force-LoopBreak</option></term>
> <listitem><para>Never Enable this option unless you -really- know what you are doing. It
<listitem>
<para>
Never enable this option unless you <emphasis>really</emphasis>
know what you are doing. It
> permits APT to temporarily remove an essential package to break a
> Conflicts/Conflicts or Conflicts/Pre-Depend loop between two essential
Depends
> packages. SUCH A LOOP SHOULD NEVER EXIST AND IS A GRAVE BUG. This option
packages. <emphasis>Such a loop should never exist and is a grave
bug.</emphasis> This option
> will work if the essential packages are not tar, gzip, libc, dpkg, bash or
<literal>tar</literal> (etc.)
> anything that those packages depend on.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Cache-Start</option></term><term><option>Cache-Grow</option></term><term><option>Cache-Limit</option></term>
> <listitem><para>APT uses since version 0.7.26 a resizable memory mapped cache file to store the 'available'
Should "'available'" be in <literal> tags or something?
> information. <literal>Cache-Start</literal> acts as a hint to which size the Cache will grow
Tricky - try "acts as a hint of the size the cache will grow to, and..."
> and is therefore the amount of memory APT will request at startup. The default value is
> 20971520 bytes (~20 MB). Note that this amount of space needs to be available for APT
^
Add final semicolon
> otherwise it will likely fail ungracefully, so for memory restricted devices this value should
> be lowered while on systems with a lot of configured sources it should be increased.
> <literal>Cache-Grow</literal> defines in bytes with the default of 1048576 (~1 MB) how much
> the Cache size will be increased in the event the space defined by <literal>Cache-Start</literal>
c
> is not enough. These value will be applied again and again until either the cache is big
values
> enough to store all information or the size of the cache reaches the <literal>Cache-Limit</literal>.
> The default of <literal>Cache-Limit</literal> is 0 which stands for no limit.
> If <literal>Cache-Grow</literal> is set to 0 the automatic grow of the cache is disabled.
growth
> </para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Build-Essential</option></term>
> <listitem><para>Defines which package(s) are considered essential build dependencies.</para></listitem>
^^^
Just "packages" - how likely is it to be singular?
> </varlistentry>
>
> <varlistentry><term><option>Get</option></term>
> <listitem><para>The Get subsection controls the &apt-get; tool, please see its
;
> documentation for more information about the options here.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Cache</option></term>
> <listitem><para>The Cache subsection controls the &apt-cache; tool, please see its
;
> documentation for more information about the options here.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>CDROM</option></term>
> <listitem><para>The CDROM subsection controls the &apt-cdrom; tool, please see its
;
> documentation for more information about the options here.</para></listitem>
> </varlistentry>
> </variablelist>
> </refsect1>
>
> <refsect1><title>The Acquire Group</title>
> <para>The <literal>Acquire</literal> group of options controls the download of packages
> and the URI handlers.
Make that something like
and the various "acquire methods" (that is, URI handling schemes).
to establish this jargon before it crops up bafflingly much later.
> <variablelist>
> <varlistentry><term><option>Check-Valid-Until</option></term>
> <listitem><para>Security related option defaulting to true as an
> expiring validation for a Release file prevents longtime replay attacks
> and can e.g. also help users to identify no longer updated mirrors -
> but the feature depends on the correctness of the time on the user system.
> Archive maintainers are encouraged to create Release files with the
> <literal>Valid-Until</literal> header, but if they don't or a stricter value
> is volitional the following <literal>Max-ValidTime</literal> option can be used.
> </para></listitem>
> </varlistentry>
Make that:
<listitem>
<para>
Security related option defaulting to true, as giving a Release file's
validation an expiration date prevents replay attacks over a long
timescale, and can also for example help users to identify mirrors
that are no longer updated - but the feature depends on the
correctness of the clock on the user system. Archive maintainers are
encouraged to create Release files with the
<literal>Valid-Until</literal> header, but if they don't or a
stricter value is desired the <literal>Max-ValidTime</literal>
option below can be used.
</para>
</listitem>
>
> <varlistentry><term><option>Max-ValidTime</option></term>
> <listitem><para>Seconds the Release file should be considered valid after
> it was created (indicated by the <literal>Date</literal> header).
How long (in seconds) the <filename>Release</filename> file should be
considered valid after the time of its creation as indicated by the
<literal>Date</literal> header
or perhaps, to match the following,
Maximum time (in seconds) after its creation (as indicated by the
<literal>Date</literal> header) that the <filename>Release</filename>
file should be considered valid.
> If the Release file itself includes a <literal>Valid-Until</literal> header
> the earlier date of the two is used as the expiration date.
> The default value is <literal>0</literal> which stands for "for ever valid".
"valid forever"
> Archive specific settings can be made by appending the label of the archive
> to the option name.
> </para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Min-ValidTime</option></term>
> <listitem><para>Minimum of seconds the Release file should be considered
> valid after it was created (indicated by the <literal>Date</literal> header).
Minimum time (in seconds) after its creation (as indicated by the
<literal>Date</literal> header) that the <filename>Release</filename>
file should be considered valid.
> Use this if you need to use a seldomly updated (local) mirror of a more
^^
"Seldom" is already an adverb, so either "seldom updated" or "rarely updated".
> regular updated archive with a <literal>Valid-Until</literal> header
"Regularly" or (more to the point) "frequently".
> instead of completely disabling the expiration date checking.
> Archive specific settings can and should be used by appending the label of
> the archive to the option name.
> </para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>PDiffs</option></term>
> <listitem><para>Try to download deltas called <literal>PDiffs</literal> for
> Packages or Sources files instead of downloading whole ones. True
Add tags, in this case I suppose <filename> tags.
> by default.</para>
> <para>Two sub-options to limit the use of PDiffs are also available:
> With <literal>FileLimit</literal> can be specified how many PDiff files
> are downloaded at most to update a file. <literal>SizeLimit</literal>
Two sub-options to limit the use of PDiffs are also available:
<literal>FileLimit</literal> can be used to specify a maximum number of
PDiff files should be downloaded to update a file. <literal>SizeLimit</literal>
> on the other hand is the maximum percentage of the size of all patches
> compared to the size of the targeted file. If one of these limits is
> exceeded the complete file is downloaded instead of the patches.
> </para></listitem>
> </varlistentry>
[...]
> <varlistentry><term><option>http</option></term>
> <listitem><para>HTTP URIs; http::Proxy is the default http proxy to use. It is in the
Huh? Oh, right, it's acting as if "HTTP URIs" was a sort of
subheading. No, just say:
<listitem>
<para>
<literal>http::Proxy<literal> sets the default proxy to use for HTTP
URIs. It is in the
> standard form of <literal>http://[[user][:pass]@]host[:port]/</literal>. Per
> host proxies can also be specified by using the form
> <literal>http::Proxy::<host></literal> with the special keyword <literal>DIRECT</literal>
> meaning to use no proxies. If no one of the above settings is specified,
> <envar>http_proxy</envar> environment variable
> will be used.</para>
>
> <para>Three settings are provided for cache control with HTTP/1.1 compliant
> proxy caches. <literal>No-Cache</literal> tells the proxy to not use its cached
> response under any circumstances, <literal>Max-Age</literal> is sent only for
> index files and tells the cache to refresh its object if it is older than
If I understand this correctly it needs some grammar fixes:
proxy caches. <literal>No-Cache</literal> tells the proxy not to use its
cached response under any circumstances, sending
<literal>Max-Age</literal> only for index files and telling the cache to
refresh its object if it is older than
> the given number of seconds. Debian updates its index files daily so the
> default is 1 day. <literal>No-Store</literal> specifies that the cache should never
> store this request, it is only set for archive files. This may be useful
What request? Just "requests"?
> to prevent polluting a proxy cache with very large .deb files. Note:
> Squid 2.0.2 does not support any of these options.</para>
This note seems fairly useless when oldstable has 2.7.STABLE3.
> <para>The option <literal>timeout</literal> sets the timeout timer used by the method,
s/,/;/
> this applies to all things including connection timeout and data timeout.</para>
All "things"?
> <para>The setting <literal>Acquire::http::Pipeline-Depth</literal> can be used to
> enabled HTTP pipeling (RFC 2616 section 8.1.2.2) which can be beneficial e.g. on
"to enable HTTP pipelining"
> high-latency connections. It specifies how many requests are send in a pipeline.
"are sent"
> Previous APT versions had a default of 10 for this setting, but the default value
> is now 0 (= disabled) to avoid problems with the ever-growing amount of webservers
> and proxies which choose to not conform to the HTTP/1.1 specification.</para>
>
> <para><literal>Acquire::http::AllowRedirect</literal> controls if APT will follow
Pedantically, s/if/whether/
> redirects, which is enabled by default.</para>
>
> <para>The used bandwidth can be limited with <literal>Acquire::http::Dl-Limit</literal>
> which accepts integer values in kilobyte. The default value is 0 which deactivates
s
> the limit and tries uses as much as possible of the bandwidth (Note that this option implicit
the limit and tries to use all available bandwidth (note that this option implicitly
> deactivates the download from multiple servers at the same time.)</para>
Perhaps this should be "implicitly disables downloading from..."
> <para><literal>Acquire::http::User-Agent</literal> can be used to set a different
> User-Agent for the http download method as some proxies allow access for clients
> only if the client uses a known identifier.</para>
> </listitem>
> </varlistentry>
>
> <varlistentry><term><option>https</option></term>
> <listitem><para>HTTPS URIs. Cache-control, Timeout, AllowRedirect, Dl-Limit and
> proxy options are the same as for <literal>http</literal> method and will also
> default to the options from the <literal>http</literal> method if they are not
> explicitly set for https. <literal>Pipeline-Depth</literal> option is not
> supported yet.</para>
Again, just sticking in "HTTPS URIs" doesn't make it a subheading. I
would recommend:
<listitem>
<para>
The <literal>Cache-control</literal>, <literal>Timeout</literal>,
<literal>AllowRedirect</literal>, <literal>Dl-Limit</literal> and
<literal>proxy</literal> options work for HTTPS URIs in the same way
as for the <literal>http</literal> method, and default to the same
values if they are not explicitly set. The
<literal>Pipeline-Depth</literal> option is not yet supported.
</para>
>
> <para><literal>CaInfo</literal> suboption specifies place of file that
> holds info about trusted certificates.
Shouldn't all these be formatted as a sublist or something?
<para>
The <literal>CaInfo</literal> suboption specifies the location of a
file that contains information about trusted certificates.
> <literal><host>::CaInfo</literal> is corresponding per-host option.
^the
and s/is corresponding/is the corresponding/ for all the following too.
> <literal>Verify-Peer</literal> boolean suboption determines whether verify
> server's host certificate against trusted certificates or not.
The <literal>Verify-Peer</literal> boolean suboption determines whether
or not the server's host certificate should be verified against the
trusted certificates.
> <literal><host>::Verify-Peer</literal> is corresponding per-host option.
> <literal>Verify-Host</literal> boolean suboption determines whether verify
> server's hostname or not.
<literal><host>::Verify-Peer</literal> is the corresponding per-host option.
The <literal>Verify-Host</literal> boolean suboption determines
whether or not the server's hostname should be verified.
> <literal><host>::Verify-Host</literal> is corresponding per-host option.
> <literal>SslCert</literal> determines what certificate to use for client
> authentication. <literal><host>::SslCert</literal> is corresponding per-host option.
> <literal>SslKey</literal> determines what private key to use for client
> authentication. <literal><host>::SslKey</literal> is corresponding per-host option.
> <literal>SslForceVersion</literal> overrides default SSL version to use.
> Can contain 'TLSv1' or 'SSLv3' string.
It can contain either of the strings <literal>TLSv1</literal> or
<literal>SSLv3</literal>.
> <literal><host>::SslForceVersion</literal> is corresponding per-host option.
> </para></listitem></varlistentry>
>
> <varlistentry><term><option>ftp</option></term>
> <listitem><para>FTP URIs; ftp::Proxy is the default ftp proxy to use. It is in the
Exactly as above,
<listitem>
<para>
<literal>ftp::Proxy<literal> sets the default proxy to use for FTP
URIs. It is in the
> standard form of <literal>ftp://[[user][:pass]@]host[:port]/</literal>. Per
> host proxies can also be specified by using the form
> <literal>ftp::Proxy::<host></literal> with the special keyword <literal>DIRECT</literal>
> meaning to use no proxies. If no one of the above settings is specified,
> <envar>ftp_proxy</envar> environment variable
> will be used. To use a ftp
an FTP
> proxy you will have to set the <literal>ftp::ProxyLogin</literal> script in the
> configuration file. This entry specifies the commands to send to tell
> the proxy server what to connect to. Please see
> &configureindex; for an example of
> how to do this. The substitution variables available are
> <literal>$(PROXY_USER)</literal> <literal>$(PROXY_PASS)</literal> <literal>$(SITE_USER)</literal>
> <literal>$(SITE_PASS)</literal> <literal>$(SITE)</literal> and <literal>$(SITE_PORT)</literal>
Insert commas between list items.
> Each is taken from it's respective URI component.</para>
Bogus apostrophe, and they aren't "respective" (that is, they aren't
given in an order that corresponds to a list given earlier).
Each variable represents the corresponding URI component.
</para>
> <para>The option <literal>timeout</literal> sets the timeout timer used by the method,
> this applies to all things including connection timeout and data timeout.</para>
s/,/;/ and I'm not surewhat to do with the "things".
> <para>Several settings are provided to control passive mode. Generally it is
> safe to leave passive mode on, it works in nearly every environment.
;
> However some situations require that passive mode be disabled and port
,
> mode ftp used instead. This can be done globally, for connections that
FTP
> go through a proxy or for a specific host (See the sample config file
> for examples).</para>
How many possibilities is that? Is it
This can be done a) globally, for connections that go through a proxy, or
b) for a specific host
or
This can be done a) globally,
b) for connections that go through a proxy, or
c) for a specific host
If it's the former, put the "proxy" bit in parentheses; if it's the
latter, add an "or" after "globally".
And unless there's a full stop before it, s/See/see/.
> <para>It is possible to proxy FTP over HTTP by setting the <envar>ftp_proxy</envar>
> environment variable to a http url - see the discussion of the http method
an HTTP URL
> above for syntax. You cannot set this in the configuration file and it is
> not recommended to use FTP over HTTP due to its low efficiency.</para>
>
> <para>The setting <literal>ForceExtended</literal> controls the use of RFC2428
> <literal>EPSV</literal> and <literal>EPRT</literal> commands. The default is false, which means
> these commands are only used if the control connection is IPv6. Setting this
> to true forces their use even on IPv4 connections. Note that most FTP servers
> do not support RFC2428.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>cdrom</option></term>
Now, the literal token may be <literal>cdrom</literal>, but the actual
things it pulls packages off aren't CDROMs; they're CD-ROMS, DVDs,
Blu-Ray discs, and other similar media.
> <listitem><para>CDROM URIs; the only setting for CDROM URIs is the mount point,
> <literal>cdrom::Mount</literal> which must be the mount point for the CDROM drive
> as specified in <filename>/etc/fstab</filename>. It is possible to provide
> alternate mount and unmount commands if your mount point cannot be listed
> in the fstab (such as an SMB mount and old mount packages). The syntax
> is to put <literallayout>/cdrom/::Mount "foo";</literallayout> within
> the cdrom block. It is important to have the trailing slash. Unmount
> commands can be specified using UMount.</para></listitem>
> </varlistentry>
What's this about SMB mounts and old mount packages? These days "SMB"
is CIFS, and it's perfectly possible to put it in fstab, so I'm just
going to drop those nonsensical examples - it's a pity the alternative
mount command given is nothing more coherent than "foo".
<listitem>
<para>
For URIs using the <literal>cdrom</literal> method, the only
configurable option is the mount point,
<literal>cdrom::Mount</literal>, which must be the mount point for the
CD-ROM (or DVD, or whatever) drive
as specified in <filename>/etc/fstab</filename>. It is possible to provide
alternate mount and unmount commands if your mount point cannot be listed
in the fstab. The syntax
is to put <literallayout>/cdrom/::Mount "foo";</literallayout> within
the <literal>cdrom</literal> block. It is important to have the trailing slash.
Unmount commands can be specified using UMount.
</para>
</listitem>
</varlistentry>
> <varlistentry><term><option>gpgv</option></term>
> <listitem><para>GPGV URIs; the only option for GPGV URIs is the option to pass additional parameters to gpgv.
> <literal>gpgv::Options</literal> Additional options passed to gpgv.
> </para></listitem>
> </varlistentry>
Why so repetitive?
<listitem>
<para>
For GPGV URIs the only configurable option is
<literal>gpgv::Options</literal>, which passes additional parameters
to gpgv.
</para>
</listitem>
</varlistentry>
> <varlistentry><term><option>CompressionTypes</option></term>
> <listitem><para>List of compression types which are understood by the acquire methods.
List? What list? s/List/This option contains the list/?
> Files like <filename>Packages</filename> can be available in various compression formats.
> Per default the acquire methods can decompress <command>bzip2</command>, <command>lzma</command>
By default
> and <command>gzip</command> compressed files, with this setting more formats can be added
;
> on the fly or the used method can be changed. The syntax for this is:
> <synopsis>Acquire::CompressionTypes::<replaceable>FileExtension</replaceable> "<replaceable>Methodname</replaceable>";</synopsis>
> </para><para>Also the <literal>Order</literal> subgroup can be used to define in which order
,
> the acquire system will try to download the compressed files. The acquire system will try the first
> and proceed with the next compression type in this list on error, so to prefer one over the other type
> simple add the preferred type at first - not already added default types will be added at run time
y XX default types not already added will be implicitly appended
> to the end of the list, so e.g. <synopsis>Acquire::CompressionTypes::Order:: "gz";</synopsis> can
> be used to prefer <command>gzip</command> compressed files over <command>bzip2</command> and <command>lzma</command>.
> If <command>lzma</command> should be preferred over <command>gzip</command> and <command>bzip2</command> the
> configure setting should look like this <synopsis>Acquire::CompressionTypes::Order { "lzma"; "gz"; };</synopsis>
:
> It is not needed to add <literal>bz2</literal> explicit to the list as it will be added automatic.</para>
to the list explicitly as it will be added automatically.
> <para>Note that at run time the <literal>Dir::Bin::<replaceable>Methodname</replaceable></literal> will
> be checked: If this setting exists the method will only be used if this file exists, e.g. for
> the bzip2 method (the inbuilt) setting is: <literallayout>Dir::Bin::bzip2 "/bin/bzip2";</literallayout>
<para>
Note that the
<literal>Dir::Bin::<replaceable>Methodname</replaceable></literal>
will be checked at run time. If this option has been set, the
method will only be used if this file exists; e.g. for the
<literal>bzip2</literal> method (the inbuilt) setting is:
<literallayout>Dir::Bin::bzip2 "/bin/bzip2";</literallayout>
> Note also that list entries specified on the command line will be added at the end of the list
> specified in the configuration files, but before the default entries. To prefer a type in this case
> over the ones specified in the configuration files you can set the option direct - not in list style.
> This will not override the defined list, it will only prefix the list with this type.</para>
;
> <para>The special type <literal>uncompressed</literal> can be used to give uncompressed files a
> preference, but note that most archives don't provide uncompressed files so this is mostly only
> useable for local mirrors.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>GzipIndexes</option></term>
> <listitem><para>
> When downloading <literal>gzip</literal> compressed indexes (Packages, Sources, or
> Translations), keep them gzip compressed locally instead of unpacking
> them. This saves quite a lot of disk space at the expense of more CPU
> requirements when building the local package caches. False by default.
> </para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Languages</option></term>
> <listitem><para>The Languages subsection controls which <filename>Translation</filename> files are downloaded
> and in which order APT tries to display the Description-Translations. APT will try to display the first
~ ~
Is this capitalisation strictly necessary?
> available Description in the Language which is listed at first. Languages can be defined with their
~ ~ XX
If Language is referring to the literal, it should be in tags; if not,
it should be lowercase. Description should definitely be lowercase.
> short or long Languagecodes. Note that not all archives provide <filename>Translation</filename>
~ ^
Two words: "language codes".
> files for every Language - especially the long Languagecodes are rare, so please
~ the long language codes are especially rare,
> inform you which ones are available before you set here impossible values.</para>
check which ones are available before you set unavailable values here.
> <para>The default list includes "environment" and "en". "<literal>environment</literal>" has a special meaning here:
> It will be replaced at runtime with the languagecodes extracted from the <literal>LC_MESSAGES</literal> environment variable.
it ^
> It will also ensure that these codes are not included twice in the list. If <literal>LC_MESSAGES</literal>
> is set to "C" only the <filename>Translation-en</filename> file (if available) will be used.
> To force apt to use no Translation file use the setting <literal>Acquire::Languages=none</literal>. "<literal>none</literal>"
APT
> is another special meaning code which will stop the search for a fitting <filename>Translation</filename> file.
suitable
> This can be used by the system administrator to let APT know that it should download also this files without
> actually use them if the environment doesn't specify this languages. So the following example configuration will
> result in the order "en, de" in an english and in "de, en" in a german localization. Note that "fr" is downloaded,
> but not used if APT is not used in a french localization, in such an environment the order would be "fr, de, en".
I don't follow this. It's something like:
This tells APT to download these translations too, without actually
using them unless the environment specifies the languages. So the
following example configuration will result in the order "en, de" in an
English locale or "de, en" in a German one. Note that "fr" is
downloaded, but not used unless APT is used in a French locale (where
the order would be "fr, de, en").
But it seems to imply that there's some situation where you'd want
(e.g) German translations to be automatically used when you're running
in a French locale, and I don't understand why.
> <programlisting>Acquire::Languages { "environment"; "de"; "en"; "none"; "fr"; };</programlisting></para>
> <para>Note: To prevent problems resulting from APT being executed in different environments
> (e.g. by different users or by other programs) all Translation files which are found in
> <filename>/var/lib/apt/lists/</filename> will be added to the end of the list
> (after an implicit "<literal>none</literal>").</para>
> </listitem>
> </varlistentry>
>
> </variablelist>
> </para>
> </refsect1>
>
> <refsect1><title>Directories</title>
>
> <para>The <literal>Dir::State</literal> section has directories that pertain to local
> state information. <literal>lists</literal> is the directory to place downloaded
> package lists in and <literal>status</literal> is the name of the dpkg status file.
> <literal>preferences</literal> is the name of the APT <filename>preferences</filename> file.
> <literal>Dir::State</literal> contains the default directory to prefix on all sub
> items if they do not start with <filename>/</filename> or <filename>./</filename>.</para>
Hyphenate "sub-items", since the items aren't in any sense subs.
> <para><literal>Dir::Cache</literal> contains locations pertaining to local cache
> information, such as the two package caches <literal>srcpkgcache</literal> and
> <literal>pkgcache</literal> as well as the location to place downloaded archives,
> <literal>Dir::Cache::archives</literal>. Generation of caches can be turned off
> by setting their names to be blank. This will slow down startup but
by setting their names to the empty string.
> save disk space. It is probably preferred to turn off the pkgcache rather
preferable (?)
> than the srcpkgcache. Like <literal>Dir::State</literal> the default
> directory is contained in <literal>Dir::Cache</literal></para>
>
> <para><literal>Dir::Etc</literal> contains the location of configuration files,
> <literal>sourcelist</literal> gives the location of the sourcelist and
> <literal>main</literal> is the default configuration file (setting has no effect,
> unless it is done from the config file specified by
> <envar>APT_CONFIG</envar>).</para>
>
> <para>The <literal>Dir::Parts</literal> setting reads in all the config fragments in
> lexical order from the directory specified. After this is done then the
> main config file is loaded.</para>
>
> <para>Binary programs are pointed to by <literal>Dir::Bin</literal>. <literal>Dir::Bin::Methods</literal>
> specifies the location of the method handlers and <literal>gzip</literal>,
> <literal>bzip2</literal>, <literal>lzma</literal>,
> <literal>dpkg</literal>, <literal>apt-get</literal> <literal>dpkg-source</literal>
> <literal>dpkg-buildpackage</literal> and <literal>apt-cache</literal> specify the location
> of the respective programs.</para>
(This time "respective" more or less fits.)
[...]
> <refsect1><title>APT in DSelect</title>
> <para>
> When APT is used as a &dselect; method several configuration directives
> control the default behaviour. These are in the <literal>DSelect</literal> section.</para>
or
>
> <variablelist>
> <varlistentry><term><option>Clean</option></term>
> <listitem><para>Cache Clean mode; this value may be one of always, prompt, auto,
> pre-auto and never. always and prompt will remove all packages from
Literalise.
> the cache after upgrading, prompt (the default) does so conditionally.
> auto removes only those packages which are no longer downloadable
> (replaced with a new version for instance). pre-auto performs this
> action before downloading new packages.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>options</option></term>
> <listitem><para>The contents of this variable is passed to &apt-get; as command line
are
> options when it is run for the install phase.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Updateoptions</option></term>
> <listitem><para>The contents of this variable is passed to &apt-get; as command line
are
> options when it is run for the update phase.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>PromptAfterUpdate</option></term>
> <listitem><para>If true the [U]pdate operation in &dselect; will always prompt to continue.
> The default is to prompt only on error.</para></listitem>
> </varlistentry>
> </variablelist>
> </refsect1>
>
> <refsect1><title>How APT calls dpkg</title>
> <para>Several configuration directives control how APT invokes &dpkg;. These are
> in the <literal>DPkg</literal> section.</para>
>
> <variablelist>
> <varlistentry><term><option>options</option></term>
> <listitem><para>This is a list of options to pass to dpkg. The options must be specified
&dpkg;.
> using the list notation and each list item is passed as a single argument
> to &dpkg;.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Pre-Invoke</option></term><term><option>Post-Invoke</option></term>
> <listitem><para>This is a list of shell commands to run before/after invoking &dpkg;.
> Like <literal>options</literal> this must be specified in list notation. The
> commands are invoked in order using <filename>/bin/sh</filename>, should any
;
> fail APT will abort.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Pre-Install-Pkgs</option></term>
> <listitem><para>This is a list of shell commands to run before invoking dpkg. Like
&dpkg;.
> <literal>options</literal> this must be specified in list notation. The commands
> are invoked in order using <filename>/bin/sh</filename>, should any fail APT
;
> will abort. APT will pass to the commands on standard input the
> filenames of all .deb files it is going to install, one per line.</para>
"the commands on standard input"? Oh, you mean:
will abort. APT will pass the filenames of all .deb files it is going to
install to the commands, one per line on standard input.
</para>
>
> <para>Version 2 of this protocol dumps more information, including the
> protocol version, the APT configuration space and the packages, files
> and versions being changed. Version 2 is enabled by setting
> <literal>DPkg::Tools::options::cmd::Version</literal> to 2. <literal>cmd</literal> is a
> command given to <literal>Pre-Install-Pkgs</literal>.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Run-Directory</option></term>
> <listitem><para>APT chdirs to this directory before invoking dpkg, the default is
&dpkg;;
> <filename>/</filename>.</para></listitem>
> </varlistentry>
>
> <varlistentry><term><option>Build-options</option></term>
> <listitem><para>These options are passed to &dpkg-buildpackage; when compiling packages,
;
> the default is to disable signing and produce all binaries.</para></listitem>
> </varlistentry>
> </variablelist>
>
> <refsect2><title>dpkg trigger usage (and related options)</title>
> <para>APT can call dpkg in a way so it can make aggressive use of triggers over
APT can call &dpkg; in such a way as to let it make aggressive use of triggers over
(and s/dpkg/&dpkg;/ throughout:)
> multiple calls of dpkg. Without further options dpkg will use triggers only in between his
> own run. Activating these options can therefore decrease the time needed to perform the
"Only in between his own run"? Does it mean "only once each time it runs"?
> install / upgrade. Note that it is intended to activate these options per default in the
install or upgrade.
> future, but as it changes the way APT calling dpkg drastically it needs a lot more testing.
drastically changes the way APT calls &dpkg;
> <emphasis>These options are therefore currently experimental and should not be used in
> productive environments.</emphasis> Also it breaks the progress reporting so all frontends will
ion It also breaks progress reporting such that all front-ends will
(What does it mean by "frontends" anyway? Seemingly not aptitude etc;
and things like the http acquire are more like "back-ends".)
> currently stay around half (or more) of the time in the 100% state while it actually configures
> all packages.</para>
> <para>Note that it is not guaranteed that APT will support these options or that these options will
> not cause (big) trouble in the future. If you have understand the current risks and problems with
> these options, but are brave enough to help testing them create a new configuration file and test a
,
> combination of options. Please report any bugs, problems and improvements you encounter and make sure
> to note which options you have used in your reports. Asking dpkg for help could also be useful for
> debugging proposes, see e.g. <command>dpkg --audit</command>. A defensive option combination would be
> <literallayout>DPkg::NoTriggers "true";
> PackageManager::Configure "smart";
> DPkg::ConfigurePending "true";
> DPkg::TriggersPending "true";</literallayout></para>
>
> <variablelist>
> <varlistentry><term><option>DPkg::NoTriggers</option></term>
> <listitem><para>Add the no triggers flag to all dpkg calls (except the ConfigurePending call).
> See &dpkg; if you are interested in what this actually means. In short: dpkg will not run the
> triggers when this flag is present unless it is explicitly called to do so in an extra call.
> Note that this option exists (undocumented) also in older apt versions with a slightly different
> meaning: Previously these option only append --no-triggers to the configure calls to dpkg -
> now apt will add these flag also to the unpack and remove calls.</para></listitem>
APT will also add this flag
> </varlistentry>
>
> <varlistentry><term><option>PackageManager::Configure</option></term>
> <listitem><para>Valid values are "<literal>all</literal>", "<literal>smart</literal>" and "<literal>no</literal>".
> "<literal>all</literal>" is the default value and causes APT to configure all packages explicit.
> The "<literal>smart</literal>" way is it to configure only packages which need to be configured before
> another package can be unpacked (Pre-Depends) and let the rest configure by dpkg with a call generated
> by the next option. "<literal>no</literal>" on the other hand will not configure anything and totally
> rely on dpkg for configuration (which will at the moment fail if a Pre-Depends is encountered).
> Setting this option to another than the all value will implicitly activate also the next option per
> default as otherwise the system could end in an unconfigured status which could be unbootable!
The default value is "<literal>all</literal>", which causes APT to
configure all packages. The "<literal>smart</literal>" way is to
configure only packages which need to be configured before another
package can be unpacked (Pre-Depends), and let the rest be configured
by &dpkg; with a call generated by the ConfigurePending option (see
below). On the other hand, "<literal>no</literal>" will not configure
anything, and totally relies on &dpkg; for configuration (which at the
moment will fail if a Pre-Depends is encountered). Setting this option
to any value other than <literal>all</literal> will implicitly also
activate the next option by default, as otherwise the system could end
in an unconfigured and potentially unbootable state.
> </para></listitem>
> </varlistentry>
> <varlistentry><term><option>DPkg::ConfigurePending</option></term>
> <listitem><para>If this option is set apt will call <command>dpkg --configure --pending</command>
, APT
> to let dpkg handle all required configurations and triggers. This option is activated automatic
Automatic-ally.
> per default if the previous option is not set to <literal>all</literal>, but deactivating could be useful
Deactivating ^it^.
> if you want to run APT multiple times in a row - e.g. in an installer. In these sceneries you could
When you say "installer" you mean "initial OS installer", right?
> deactivate this option in all but the last run.</para></listitem>
> </varlistentry>
> <varlistentry><term><option>DPkg::TriggersPending</option></term>
> <listitem><para>Useful for <literal>smart</literal> configuration as a package which has pending
^the
> triggers is not considered as <literal>installed</literal> and dpkg treats them as <literal>unpacked</literal>
,
> currently which is a dealbreaker for Pre-Dependencies (see debbugs #526774). Note that this will
, showstopper
> process all triggers, not only the triggers needed to configure this package.</para></listitem>
> </varlistentry>
> <varlistentry><term><option>PackageManager::UnpackAll</option></term>
> <listitem><para>As the configuration can be deferred to be done at the end by dpkg it can be
> tried to order the unpack series only by critical needs, e.g. by Pre-Depends. Default is true
> and therefore the "old" method of ordering in various steps by everything. While both method
> were present in earlier APT versions the <literal>OrderCritical</literal> method was unused, so
> this method is very experimental and needs further improvements before becoming really useful.
I don't understand this. The default is "true", which means lots of
stuff is taken into account to decide on the right unpacking order;
the alternative presumably is "false", which only takes into account
Pre-Depends (and maybe a few other unspecified critical issues); but
there's some other thing called OrderCritical that used to exist
once, so "this method" (what?) is experimental... I don't get it.
> </para></listitem>
> </varlistentry>
> <varlistentry><term><option>OrderList::Score::Immediate</option></term>
> <listitem><para>Essential packages (and there dependencies) should be configured immediately
their
> after unpacking. It will be a good idea to do this quite early in the upgrade process as these
It is a good idea
> these configure calls require currently also <literal>DPkg::TriggersPending</literal> which
XXXXX also currently require
> will run quite a few triggers (which maybe not needed). Essentials get per default a high score
may not be needed).
> but the immediate flag is relatively low (a package which has a Pre-Depends is higher rated).
rated higher
> These option and the others in the same group can be used to change the scoring. The following
> example shows the settings with there default values.
their
> <literallayout>OrderList::Score {
> Delete 500;
> Essential 200;
> Immediate 10;
> PreDepends 50;
> };</literallayout>
> </para></listitem>
> </varlistentry>
> </variablelist>
> </refsect2>
> </refsect1>
>
> <refsect1>
> <title>Periodic and Archives options</title>
> <para><literal>APT::Periodic</literal> and <literal>APT::Archives</literal>
> groups of options configure behavior of apt periodic updates, which is
> done by <literal>/etc/cron.daily/apt</literal> script. See header of
^the
> this script for the brief documentation of these options.
There's no header field; you mean "See the comments in this script for
brief documentation of these options".
[...]
> <varlistentry>
> <term><option>Debug::pkgDepCache::Marker</option></term>
> <listitem>
> <para>
> Generate debug messages describing which package is marked
packges are
> as keep/install/remove while the ProblemResolver does his work.
> Each addition or deletion may trigger additional actions;
> they are shown indented two additional space under the original entry.
spaces
> The format for each line is <literal>MarkKeep</literal>,
> <literal>MarkDelete</literal> or <literal>MarkInstall</literal> followed by
> <literal>package-name <a.b.c -> d.e.f | x.y.z> (section)</literal>
> where <literal>a.b.c</literal> is the current version of the package,
> <literal>d.e.f</literal> is the version considered for installation and
> <literal>x.y.z</literal> is a newer version, but not considered for installation
> (because of a low pin score). The later two can be omitted if there is none or if
> it is the same version as the installed.
the same as the installed version.
> <literal>section</literal> is the name of the section the package appears in.
> </para>
> </listitem>
> </varlistentry>
>
> <!-- Question: why doesn't this do anything? The code says it should. -->
> <varlistentry>
> <term><option>Debug::pkgInitConfig</option></term>
> <listitem>
> <para>
> Dump the default configuration to standard error on
> startup.
> </para>
> </listitem>
> </varlistentry>
Shouldn't this admit to not working (and preferably point at a
bugreport)?
[...]
Finished! But I'll need a few bits of feedback..
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: