[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for Review: APT manpages



apt-extracttemplates.1.xml is trivial; the only thing I'd suggest for
it is

  <refnamediv>
     <refname>apt-extracttemplates</refname>
-    <refpurpose>Utility to extract DebConf config and templates from Debian packages</refpurpose>
+    <refpurpose>Utility to extract debconf config and templates from Debian packages</refpurpose>
  </refnamediv>

(DebConf is the annual event, debconf is the executable.)

So I'll go straight on into apt-ftparchive.1.xml.  The above was too
simple to need a patch; the following isn't ready for one yet.

[...]
>    <para>Internally <command>apt-ftparchive</command> can make use of binary databases to
>    cache the contents of a .deb file, and it does not rely on any external 
>    programs aside from &gzip;. When doing a full generate it automatically 
>    performs file-change checks and builds the desired compressed output files.</para>

This looks as if it's trying to draw some sort of internal/external
contrast, but one that makes no particular sense; perhaps it's just:

     <para><command>apt-ftparchive</command> can make use of binary databases to
     cache the contents of a .deb file. It does not rely on any external
     programs aside from &gzip;. When doing a full generate it automatically 
     performs file-change checks and builds the desired compressed output files.</para>

It's a pity we've got the word "binary" here when even if it was plain
text it would be a binary package database... and this problem of
ambiguous jargon terms just gets worse and worse as the file goes on.

[...]
>    <variablelist>
>      <varlistentry><term><option>packages</option></term>
>      <listitem><para>
>      The packages command generates a package file from a directory tree. It
>      takes the given directory and recursively searches it for .deb files, 
>      emitting a package record to stdout for each. This command is 
>      approximately equivalent to &dpkg-scanpackages;.</para>

Perhaps s/stdout/standard output/ (or s/stdout/STDOUT/) throughout.

>      <para>The option <option>--db</option> can be used to specify a binary caching DB.</para></listitem>
>      </varlistentry>
>
>      <varlistentry><term><option>sources</option></term>
>      <listitem><para>
>      The <literal>sources</literal> command generates a source index file from a directory tree.
>      It takes the given directory and recursively searches it for .dsc files,
>      emitting a source record to stdout for each. This command is approximately
>      equivalent to &dpkg-scansources;.</para>
>      <para>
>      If an override file is specified then a source override file will be
>      looked for with an extension of .src. The --source-override option can be
>      used to change the source override file that will be used.</para></listitem>
>      </varlistentry>

"Binary" can mean either pre-built package or non-text data-blob; and
"source" can mean either sourcecode bundle or APTable origin.  Here
it's using "binary" in the latter sense and "source" in the former.
Since the "source override file" is a particular file with a
particular default name it might be useful if we could just refer to 
it by name - is it "<filename>override.src</filename>"?

>      <varlistentry><term><option>contents</option></term>
>      <listitem><para>
>      The <literal>contents</literal> command generates a contents file from a directory tree. It
>      takes the given directory and recursively searches it for .deb files, 
>      and reads the file list from each file. It then sorts and writes to stdout
>      the list of files matched to packages. Directories are not written to 
>      the output. If multiple packages own the same file then each package is
>      separated by a comma in the output.</para>

To be a bit picky, they aren't *each* separated by a comma - they as a
set have comma as a separator.  Say:

                   If multiple packages own the same file then the packages are
       given as a comma-separated list in the output.</para>

>      <para>
>      The option <option>--db</option> can be used to specify a binary caching DB.</para></listitem>
>      </varlistentry>
> 
>      <varlistentry><term><option>release</option></term>
>      <listitem><para>
>      The <literal>release</literal> command generates a Release file from a
>      directory tree. It recursively searches the given directory for uncompressed
>      <filename>Packages</filename> and <filename>Sources</filename> files and the ones
                                                                                ^^^
Surplus article.  But is this still accurate?  How about InRelease
files and xz support?
 
>      compressed with <command>gzip</command>, <command>bzip2</command> or <command>lzma</command>
>      as well as <filename>Release</filename> and <filename>md5sum.txt</filename> files by default
>      (<literal>APT::FTPArchive::Release::Default-Patterns</literal>). Additional filename patterns
>      can be added by listing them in <literal>APT::FTPArchive::Release::Patterns</literal>.
>      It then writes to stdout a Release file containing a MD5, SHA1 and SHA256 digest
                         ^^^^^^   ^^^^^^^                 ^
       It then writes to standard output a <filename>Release</filename> file containing an MD5, SHA1 and SHA256 digest

[...]
> 
>  <refsect1><title>The Generate Configuration</title>

Make that "The Generate Configuration File" or "Configuration for
<literal>generate</literal>" or something.

>    <para>
>    The <literal>generate</literal> command uses a configuration file to describe the 
>    archives that are going to be generated. It follows the typical ISC 
>    configuration format as seen in ISC tools like bind 8 and dhcpd.
                                                         ^
AFAIK it's the same in bind9, so drop the version number.

>    &apt-conf; contains a description of the syntax. Note that the generate 
>    configuration is parsed in sectional manner, but &apt-conf; is parsed in a
>    tree manner. This only effects how the scope tag is handled.</para>

"In a sectional manner" and "in a tree manner" are unintelligible.
Should the latter be "hierarchically"?

"Scope tag" turns out to mean approximately "distribution tree" (AKA
"release" or "suite", but here tied to the variablename $DIST).
 
>    <para>
>    The generate configuration has 4 separate sections, each described below.</para>

Make that:
     The <literal>generate</literal> configuration file has four sections, described below.

>    <refsect2><title>Dir Section</title>
>      <para>
>      The <literal>Dir</literal> section defines the standard directories needed to 
>      locate the files required during the generation process. These 
>      directories are prepended certain relative paths defined in later 
>      sections to produce a complete an absolute path.</para>

This starts out slightly incoherent and gets worse; maybe:

       The <literal>Dir</literal> section defines the directories
       containing files used during the generation process. These
       directories are combined with the relative paths defined in later 
       sections to produce absolute paths.</para>

>      <variablelist>     
>       <varlistentry><term><option>ArchiveDir</option></term>
>       <listitem><para>
>       Specifies the root of the FTP archive, in a standard
>       Debian configuration this is the directory that contains the 
>       <filename>ls-LR</filename> and dist nodes.</para></listitem>
>       </varlistentry>

Run-on sentence, and what's a "dist node"?  Maybe this should be:

        Specifies the root of the FTP archive; in a standard
        Debian configuration this is the directory that contains
        <filename>ls-LR.gz</filename> and <filename>dists</filename>.

>       <varlistentry><term><option>OverrideDir</option></term>
>       <listitem><para>
>       Specifies the location of the override files.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>CacheDir</option></term>
>       <listitem><para>
>       Specifies the location of the cache files</para></listitem>
                                                 ^
(Trivial missing punctuation)

>       </varlistentry>
>
>       <varlistentry><term><option>FileListDir</option></term>
>       <listitem><para>
>       Specifies the location of the file list files, 
>       if the <literal>FileList</literal> setting is used below.</para></listitem>
>       </varlistentry>
>      </variablelist>
>    </refsect2>

Should that be "if the <literal>FileList</literal> setting (see
below) is used"?

>    <refsect2><title>Default Section</title>

(Shouldn't this have been called the "Defaults" section?)

>      <para>
>      The <literal>Default</literal> section specifies default values, and settings 
>      that control the operation of the generator. Other sections may override 
>      these defaults with a per-section setting.</para>
>      <variablelist>     
>       <varlistentry><term><option>Packages::Compress</option></term>
>       <listitem><para>
>       Sets the default compression schemes to use 
>       for the Package index files. It is a string that contains a space 
>       separated list of at least one of: '.' (no compression), 'gzip' and 
>       'bzip2'. The default for all compression schemes is '. gzip'.</para></listitem>
>       </varlistentry>

Unnecessary colon.  Shouldn't these strings in singlequotes here and
below instead be in <literal> tags?  And shouldn't "the Package index
files" be "the <filename>Packages</filename> file"?
 
>       <varlistentry><term><option>Packages::Extensions</option></term>
>       <listitem><para>
>       Sets the default list of file extensions that are package files.
>       This defaults to '.deb'.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>Sources::Compress</option></term>
>       <listitem><para>
>       This is similar to <literal>Packages::Compress</literal> 
>       except that it controls the compression for the Sources files.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>Sources::Extensions</option></term>
>       <listitem><para>
>       Sets the default list of file extensions that are source files.
>       This defaults to '.dsc'.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>Contents::Compress</option></term>
>       <listitem><para>
>       This is similar to <literal>Packages::Compress</literal> 
>       except that it controls the compression for the Contents files.</para></listitem>
>       </varlistentry>
> 
>       <varlistentry><term><option>Translation::Compress</option></term>
>       <listitem><para>
>       This is similar to <literal>Packages::Compress</literal> 
>       except that it controls the compression for the Translation-en master file.</para></listitem>
>       </varlistentry>
> 
>       <varlistentry><term><option>DeLinkLimit</option></term>
>       <listitem><para>
>       Specifies the number of kilobytes to delink (and 
>       replace with hard links) per run. This is used in conjunction with the 
>       per-section <literal>External-Links</literal> setting.</para></listitem>
>       </varlistentry>

Huh?  So if I set it to "1000000" then apt-ftparchive will delink a
gigabyte of stuff and replace it with hard links, even if the
directories I'm scanning are empty, or contain only unique files?  Or
is this setting a maximum or something?

And is "per-section" talking about sections in the sense defined in
Policy (admin/cli-mono/comm...)?  Eventually it turns out that no, it
means what Policy calls "archive areas" and sources.list(5) calls
"components".  But we can't change the terms used here because they're
built into the option names.

>       <varlistentry><term><option>FileMode</option></term>
>       <listitem><para>
>       Specifies the mode of all created index files. It 
>       defaults to 0644. All index files are set to this mode with no regard 
>       to the umask.</para></listitem>
>       </varlistentry>
> 
>       <varlistentry><term><option>LongDescription</option></term>
>       <listitem><para>
>       Sets if long descriptions should be included in the Packages file or split
>       out into a master Translation-en file.</para></listitem>
>       </varlistentry>
>      </variablelist>
>    </refsect2>

s/Sets if/Specifies whether/
    
>    <refsect2><title>TreeDefault Section</title>
>      <para>
>      Sets defaults specific to <literal>Tree</literal> sections. All of these
>      variables are substitution variables and have the strings $(DIST), 
>      $(SECTION) and $(ARCH) replaced with their respective values.</para>
>
>      <variablelist>     
>       <varlistentry><term><option>MaxContentsChange</option></term>
>       <listitem><para>
>       Sets  the number of kilobytes of contents 
>       files that are generated each day. The contents files are round-robined
>       so that over several days they will all be rebuilt.</para></listitem>
>       </varlistentry>

Does it genuinely mean "each day" or is it "each run"?  What does it
do if I only run it once a week?  And again, what does it do if I ask
for 1000000 on an empty repository?  Is it a maximum?
       
>       <varlistentry><term><option>ContentsAge</option></term>
>       <listitem><para>
>       Controls the number of days a contents file is allowed
>       to be checked without changing. If this limit is passed the mtime of the 
>       contents file is updated. This case can occur if the package file is 
>       changed in such a way that does not result in a new contents file 
>       [override edit for instance]. A hold off is allowed in hopes that new 
>       .debs will be installed, requiring a new file anyhow. The default is 10, 
>       the units are in days.</para></listitem>

That has minor grammar problems, but mostly it's just hard to
understand and needs a general overhaul.

        Controls the number of days a <filename>Contents</filename> file is
        allowed to go without changing. If this limit is passed, the mtime
        of the file is updated. This case can occur if the
        <filename>Packages</filename> file is only changed in ways that don't
	result in a new <filename>Contents</filename> file (such as a change
        in overrides). A delay is allowed in the hope that new .debs will be
        installed, resulting in a new file anyhow. The default is ten
        days.</para></listitem>

(This still gives no hint as to why it would matter if my Contents
file rarely gets modified.)

>       </varlistentry>
>       
>       <varlistentry><term><option>Directory</option></term>
>       <listitem><para>
>       Sets the top of the .deb directory tree. Defaults to
>       <filename>$(DIST)/$(SECTION)/binary-$(ARCH)/</filename></para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>SrcDirectory</option></term>
>       <listitem><para>
>       Sets the top of the source package directory tree. Defaults to
>       <filename>$(DIST)/$(SECTION)/source/</filename></para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>Packages</option></term>
>       <listitem><para>
>       Sets the output Packages file. Defaults to 
>       <filename>$(DIST)/$(SECTION)/binary-$(ARCH)/Packages</filename></para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>Sources</option></term>
>       <listitem><para>
>       Sets the output Sources file. Defaults to 
>       <filename>$(DIST)/$(SECTION)/source/Sources</filename></para></listitem>
>       </varlistentry>
> 
>       <varlistentry><term><option>Translation</option></term>
>       <listitem><para>
>       Set the output Translation-en master file with the long descriptions if they
          ^s

>       should be not included in the Packages file. Defaults to
>       <filename>$(DIST)/$(SECTION)/i18n/Translation-en</filename></para></listitem>
>       </varlistentry>
> 
>       <varlistentry><term><option>InternalPrefix</option></term>
>       <listitem><para>
>       Sets the path prefix that causes a symlink to be
>       considered an internal link instead of an external link. Defaults to
>       <filename>$(DIST)/$(SECTION)/</filename></para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>Contents</option></term>
>       <listitem><para>
>       Sets the output Contents file. Defaults to
>       <filename>$(DIST)/Contents-$(ARCH)</filename>. If this setting causes multiple 
>       Packages files to map onto a single Contents file (such as the default) 
>       then <command>apt-ftparchive</command> will integrate those package files 
>       together automatically.</para></listitem>
>       </varlistentry>

That should probably be "(as is the default)" and "those
<filename>Packages</filename> files".
       
>       <varlistentry><term><option>Contents::Header</option></term>
>       <listitem><para>
>       Sets header file to prepend to the contents output.</para></listitem>
>       </varlistentry>

I imagine this means
        Sets a header file, which if it exists will be prepended to the contents output.
 
>       <varlistentry><term><option>BinCacheDB</option></term>
>       <listitem><para>
>       Sets the binary cache database to use for this 
>       section. Multiple sections can share the same database.</para></listitem>
>       </varlistentry>

Again, which sense of "section"?

>       <varlistentry><term><option>FileList</option></term>
>       <listitem><para>
>       Specifies that instead of walking the directory tree, 
>       <command>apt-ftparchive</command> should read the list of files from the given 
>       file. Relative files names are prefixed with the archive directory.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>SourceFileList</option></term>
>       <listitem><para>
>       Specifies that instead of walking the directory tree, 
>       <command>apt-ftparchive</command> should read the list of files from the given 
>       file. Relative files names are prefixed with the archive directory. 
>       This is used when processing source indexes.</para></listitem>
>       </varlistentry>
>      </variablelist>     
>    </refsect2>
>    
>    <refsect2><title>Tree Section</title>
>      <para>
>      The <literal>Tree</literal> section defines a standard Debian file tree which 
>      consists of a base directory, then multiple sections in that base
>      directory and finally multiple Architectures in each section. The exact 
>      pathing used is defined by the <literal>Directory</literal> substitution variable.</para> 

This was finally enough information (given that the standard tree has
leaves like "/debian/dists/stable/main/binary-amd64/Release") for me
to deduce what this man page means by "section" (except when it means
"portion of the config file", of course).

I'm also unconvinced by "pathing".  Does it mean "path structure"?

>      <para>
>      The <literal>Tree</literal> section takes a scope tag which sets the 
>      <literal>$(DIST)</literal> variable and defines the root of the tree 
>      (the path is prefixed by <literal>ArchiveDir</literal>).
>      Typically this is a setting such as <filename>dists/&stable-codename;</filename>.</para>

The part about scope tags was also totally inscrutable.  And how is it
defining the *root* of the directory tree if ArchiveDir functions as a
prefix to it?  I think it's saying:

       The <literal>Tree</literal> section is a string such as
       <filename>dists/&stable-codename;</filename>, which serves to set the
       <literal>$(DIST)</literal> variable and defines a standard
       Debian file tree beneath the <literal>ArchiveDir</literal>.

>      <para>
>      All of the settings defined in the <literal>TreeDefault</literal> section can be
>      use in a <literal>Tree</literal> section as well as three new variables.</para>
         ^
"Can be used".  But how do the three new variables fit into this
sentence?  Maybe it's trying to say:

       A <literal>Tree</literal> section can override any of the settings defined in the
       <literal>TreeDefault</literal> section, or can set one or more of the three new
       variables defined below.

>      <para>
>      When processing a <literal>Tree</literal> section <command>apt-ftparchive</command> 
>      performs an operation similar to:
>      <programlisting>
> for i in Sections do 
>    for j in Architectures do
>       Generate for DIST=scope SECTION=i ARCH=j
>      </programlisting></para>

We could at least get rid of this idiosyncratic use of "scope".

>      <variablelist>     
>       <varlistentry><term><option>Sections</option></term>
>       <listitem><para>
>       This is a space separated list of sections which appear 
>       under the distribution, typically this is something like 
>       <literal>main contrib non-free</literal></para></listitem>
>       </varlistentry>

Okay, so we can't fix the terminology, but at least I can fix the
punctuation...

        This is a space-separated list of sections which appear
        under the distribution; typically this is something like
        <literal>main contrib non-free</literal></para></listitem>

This is the first and last time it uses the word "distribution", by
which it means "suite" AKA "release" AKA (in this file) "scope".  Is
it worth trying to make this clearer and more standard?
       
>       <varlistentry><term><option>Architectures</option></term>
>       <listitem><para>
>       This is a space separated list of all the 
>       architectures that appear under search section. The special architecture 
>       'source' is used to indicate that this tree has a source archive.</para></listitem>
>       </varlistentry>

Should "search" be "each"?  Should 'source' be
<literal>source</literal>?
 
>       <varlistentry><term><option>LongDescription</option></term>
>       <listitem><para>
>       Sets if long descriptions should be included in the Packages file or split
>       out into a master Translation-en file.</para></listitem>
>       </varlistentry>

Again s/sets if/specifies whether/, and <filename>.
 
>       <varlistentry><term><option>BinOverride</option></term>
>       <listitem><para>
>       Sets the binary override file. The override file 
>       contains section, priority and maintainer address information.</para></listitem>
>       </varlistentry>

At this point it stops consistently using "binary" to mean "data file"
and starts also using it to mean "of or pertaining to .deb files as
opposed to sourcecode bundles".
 
>       <varlistentry><term><option>SrcOverride</option></term>
>       <listitem><para>
>       Sets the source override file. The override file 
>       contains section information.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>ExtraOverride</option></term>
>       <listitem><para>
>       Sets the binary extra override file.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>SrcExtraOverride</option></term>
>       <listitem><para>
>       Sets the source extra override file.</para></listitem> 
>       </varlistentry>
>      </variablelist>
>    </refsect2>

Shouldn't there be at least a pointer in the direction of the
explanations of what these files are?
    
>    <refsect2><title>BinDirectory Section</title>
>      <para>
>      The <literal>bindirectory</literal> section defines a binary directory tree 
>      with no special structure. The scope tag specifies the location of 
>      the binary directory and the settings are similar to the <literal>Tree</literal> 
>      section with no substitution variables or
>      <literal>Section</literal><literal>Architecture</literal> settings.</para>

When it says "a binary directory tree" this again is "of or pertaining
to binary packages", right?  And "scope" means "suite/release/dist"?

Why are the words <literal>Section</literal> and
<literal>Architecture</literal> run into one another like that?

>      <variablelist>
>       <varlistentry><term><option>Packages</option></term>
>       <listitem><para>
>       Sets the Packages file output.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>Sources</option></term>
>       <listitem><para>
>       Sets the Sources file output. At least one of
>       <literal>Packages</literal> or <literal>Sources</literal> is required.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>Contents</option></term>
>       <listitem><para>
>       Sets the Contents file output. (optional)</para></listitem>
>       </varlistentry>

Misplaced stop.

>       
>       <varlistentry><term><option>BinOverride</option></term>
>       <listitem><para>
>       Sets the binary override file.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>SrcOverride</option></term>
>       <listitem><para>
>       Sets the source override file.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>ExtraOverride</option></term>
>       <listitem><para>
>       Sets the binary extra override file.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>SrcExtraOverride</option></term>
>       <listitem><para>
>       Sets the source extra override file.</para></listitem>
>       </varlistentry>
>       
>       <varlistentry><term><option>BinCacheDB</option></term>
>       <listitem><para>
>       Sets the cache DB.</para></listitem>
>       </varlistentry>

("BinOverride" and "BinCacheDB", with "Bin" meaning different things
in each?  Argh.)
       
>       <varlistentry><term><option>PathPrefix</option></term>
>       <listitem><para>
>       Appends a path to all the output paths.</para></listitem>
>       </varlistentry>

"Append" is an unhelpful word to use for a prefix, since it usually
means "add as a suffix" (or appendix).  Maybe:

        Sets a string to be added as a prefix to all the output paths.
       
>       <varlistentry><term><option>FileList</option></term><term><option>SourceFileList</option></term>
>       <listitem><para>
>       Specifies the file list file.</para></listitem>
>       </varlistentry>
>      </variablelist>
>    </refsect2>
>  </refsect1>
> 
> 
>  <refsect1><title>The Binary Override File</title>
>    <para>The binary override file is fully compatible with &dpkg-scanpackages;. It
>    contains 4 fields separated by spaces. The first field is the package name,
>    the second is the priority to force that package to, the third is the
>    the section to force that package to and the final field is the maintainer 
>    permutation field.</para>

s/4/four/, s/the the/the/, and so on, but more importantly,
"maintainer permutation field" sounds like something out of a mad
scientist's lab.

>    <para>The general form of the maintainer field is:
>    <literallayout>old [// oldn]* => new</literallayout>
>    or simply,
>    <literallayout>new</literallayout>
>    The first form allows a double-slash separated list of old email addresses
>    to be specified. If any of those are found then new is substituted for the
>    maintainer field. The second form unconditionally substitutes the 
>    maintainer field.</para>
>  </refsect1>

I think I finally get it:

     <para>
     The binary override file is fully compatible with &dpkg-scanpackages;. It
     contains four fields separated by spaces. The first field is the name of the
     binary package, and the other three override the values given in that
     package's control file for its priority, archive section, and maintainer.
     </para>

     <para>
     The maintainer value may simply specify replacement content for the maintainer
     field, or may have a more complex syntax:
     <literallayout>old [// alternate]* => new</literallayout>
     This format specifies a double-slash-separated list of old email addresses;
     any that occur in the control file are overridden by the new value.
     </para>
  
>  <refsect1><title>The Source Override File</title>
>    <para>
>    The source override file is fully compatible with &dpkg-scansources;. It
>    contains 2 fields separated by spaces. The first fields is the source 
>    package name, the second is the section to assign it.</para>
>  </refsect1>   

     The source override file is fully compatible with &dpkg-scansources;. It
     contains two fields separated by a space. The first field is the source
     package name, and the second is the archive area it should be assigned to.

What is the default name of the source override (aka SrcOverride)
file, though?  Is it "override.src"?  Using the name might make
things a bit clearer in a few places.

>  <refsect1><title>The Extra Override File</title>
>    <para>
>    The extra override file allows any arbitrary tag to be added or replaced
>    in the output. It has 3 columns, the first is the package, the second is
>    the tag and the remainder of the line is the new value.</para>
>  </refsect1>   

     The extra override file allows any arbitrary tag to be added or replaced
     in the output. It has three fields separated by spaces. The first field
     is the package name, the second is the name of the item to be overridden,
     and the remainder of the line is the new value.
 
>  <refsect1><title>options</title>
>    &apt-cmdblurb;
>    
>    <variablelist>
>      <varlistentry><term><option>--md5</option></term><term><option>--sha1</option></term><term><option>--sha256</option></term>
>      <listitem><para>
>      Generate the given checksum. These options default to on, when turned off the generated
>      index files will not have the checksum fields where possible.

       Generate the given checksum. These options default to on; if they are turned
       off, where possible the generated index files will lack these checksum fields.

(When isn't it possible?)

>      Configuration Items: <literal>APT::FTPArchive::<replaceable>Checksum</replaceable></literal> and
>      <literal>APT::FTPArchive::<replaceable>Index</replaceable>::<replaceable>Checksum</replaceable></literal> where
>      <literal><replaceable>Index</replaceable></literal> can be <literal>Packages</literal>, <literal>Sources</literal> or
>      <literal>Release</literal> and <literal><replaceable>Checksum</replaceable></literal> can be <literal>MD5</literal>,
>      <literal>SHA1</literal> or <literal>SHA256</literal>.</para></listitem>
>      </varlistentry>
> 
>      <varlistentry><term><option>-d</option></term><term><option>--db</option></term>
>      <listitem><para>
>      Use a binary caching DB. This has no effect on the generate command.
>      Configuration Item: <literal>APT::FTPArchive::DB</literal>.</para></listitem>
>      </varlistentry>
> 
>      <varlistentry><term><option>-q</option></term><term><option>--quiet</option></term>
>      <listitem><para>
>      Quiet; produces output suitable for logging, omitting progress indicators.
>      More q's will produce more quiet up to a maximum of 2. You can also use

"More q's up to a maximum of 2"?  Just say "Using a second q will make
it even quieter."

>      <option>-q=#</option> to set the quiet level, overriding the configuration file. 
>      Configuration Item: <literal>quiet</literal>.</para></listitem>
>      </varlistentry>
> 
>      <varlistentry><term><option>--delink</option></term>
>      <listitem><para>
>      Perform Delinking. If the <literal>External-Links</literal> setting is used then 
>      this option actually enables delinking of the files. It defaults to on and 
>      can be turned off with <option>--no-delink</option>.
>      Configuration Item: <literal>APT::FTPArchive::DeLinkAct</literal>.</para></listitem>
>      </varlistentry>

I still don't follow what it's talking about here.

>      <varlistentry><term><option>--contents</option></term>
>      <listitem><para>
>      Perform contents generation. When this option is set and package indexes
>      are being generated with a cache DB then the file listing will also be
>      extracted and stored in the DB for later use. When using the generate 
>      command this option also allows the creation of any Contents files. The 
>      default is on.
>      Configuration Item: <literal>APT::FTPArchive::Contents</literal>.</para></listitem>
>      </varlistentry>
> 
>      <varlistentry><term><option>-s</option></term><term><option>--source-override</option></term>
>      <listitem><para>
>      Select the source override file to use with the <literal>sources</literal> command.
>      Configuration Item: <literal>APT::FTPArchive::SourceOverride</literal>.</para></listitem>
>      </varlistentry>
> 
>      <varlistentry><term><option>--readonly</option></term>
>      <listitem><para>
>      Make the caching databases read only. 
>      Configuration Item: <literal>APT::FTPArchive::ReadOnlyDB</literal>.</para></listitem>
>      </varlistentry>
> 
>      <varlistentry><term><option>-a</option></term><term><option>--arch</option></term>
>      <listitem><para>Accept in the <literal>packages</literal> and <literal>contents</literal>
>      commands only package files matching <literal>*_arch.deb</literal> or
>      <literal>*_all.deb</literal> instead of all package files in the given path.
>      Configuration Item: <literal>APT::FTPArchive::Architecture</literal>.</para></listitem>
>      </varlistentry>
> 
>      <varlistentry><term><option>APT::FTPArchive::AlwaysStat</option></term>
>      <listitem><para>
>      &apt-ftparchive; caches as much as possible of metadata in a cachedb. If packages

Is this true even if I don't ask for a --db?

>      are recompiled and/or republished with the same version again, this will lead to problems
>      as the now outdated cached metadata like size and checksums will be used. With this option
>      enabled this will no longer happen as it will be checked if the file was changed.
>      Note that this option is set to "<literal>false</literal>" by default as it is not recommend
>      to upload multiply versions/builds of a package with the same versionnumber, so in theory
>      nobody will have these problems and therefore all these extra checks are useless.
>      </para></listitem>
>      </varlistentry>

Many phrasing issues.

       &apt-ftparchive; caches metadata in a database wherever possible. This will lead to problems
       if packages are recompiled and/or republished with an unchanged version number, as the cache
       will contain outdated values for metadata such as size and checksums. With this option
       enabled, this will no longer happen, as a check will be performed for changed files.
       Note that this option is set to "<literal>false</literal>" by default as it is not recommended
       to upload multiple versions/builds of a package with the same version number, so in theory
       nobody will have these problems and therefore all these extra checks are redundant.
 
>      <varlistentry><term><option>APT::FTPArchive::LongDescription</option></term>
>      <listitem><para>
>      This configuration option defaults to "<literal>true</literal>" and should only be set to
>      <literal>"false"</literal> if the Archive generated with &apt-ftparchive; also provides
>      <filename>Translation</filename> files. Note that the <filename>Translation-en</filename>
>      master file can only be created in the generate command.
>      </para></listitem>
>      </varlistentry>
> 
>      &apt-commonoptions;
>      
>    </variablelist>
>  </refsect1>
> 
> <refsect1><title>Examples</title>
> 
> <para>To create a compressed Packages file for a directory containing
> binary packages (.deb):
> 
> <programlisting>
> <command>apt-ftparchive</command> packages <replaceable>directory</replaceable> | <command>gzip</command> > <filename>Packages.gz</filename>
> </programlisting></para>
> 
> </refsect1>
> 
>  <refsect1><title>See Also</title>
>    <para>&apt-conf;</para>
>  </refsect1>
> 
>  <refsect1><title>Diagnostics</title>
>    <para><command>apt-ftparchive</command> returns zero on normal operation, decimal 100 on error.</para>
>  </refsect1>
> 
>  &manbugs;
>  
> </refentry>
 
Okay!
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: