]> git.saurik.com Git - apt.git/blobdiff - doc/acquire-additional-files.txt
revamp apt(8) to refer more instead of duplicating
[apt.git] / doc / acquire-additional-files.txt
index ab833440b100f0e1ad0076f5d343725483d7635e..a7acbbe465a6ef766612ab956d87e3f24fb52500 100644 (file)
@@ -12,18 +12,12 @@ apt-transport-https.
 For its own operation libapt needs or can make use of Packages, Sources
 and Translation-* files, which it will acquire by default, but
 a repository might contain more data files (e.g.  Contents) a frontend
-might want to use and would therefore need to be downloaded as well
-(e.g. apt-file).
+(e.g. apt-file) might want to use and would therefore need to be
+downloaded as well.
 
 This file describes the configuration scheme such a frontend can use to
 instruct the Acquire system to download those additional files.
 
-Note that you can't download files from other sources. It must be files
-in the same repository and below the Release file. The Release file must
-also contain hashes for the file itself as well as for the compressed
-file if wanted, otherwise a download isn't even tried!
-
-
 # The Configuration Stanza
 
 The Acquire system uses the same configuration settings to implement the
@@ -32,26 +26,30 @@ they would be written in a configuration file the configuration
 instructing the Acquire system to download the Packages files would look
 like this (see also apt.conf(5) manpage for configuration file syntax):
 
-       APT::Acquire::Targets::deb::Packages {
+       Acquire::IndexTargets::deb::Packages {
                MetaKey "$(COMPONENT)/binary-$(ARCHITECTURE)/Packages";
                ShortDescription "Packages";
-               Description "$(SITE) $(RELEASE)/$(COMPONENT) $(ARCHITECTURE) Packages";
+               Description "$(RELEASE)/$(COMPONENT) $(ARCHITECTURE) Packages";
 
                flatMetaKey "Packages";
-               flatDescription "$(SITE) $(RELEASE) Packages";
+               flatDescription "$(RELEASE) Packages";
 
-               Optional "false";
+               Optional "no";
        };
 
 All files which should be downloaded (nicknamed 'Targets') are mentioned
-below the APT::Acquire::Targets scope. 'deb' is here the type of the
+below the Acquire::IndexTargets scope. 'deb' is here the type of the
 sources.list entry the file should be acquired for. The only other
 supported value is hence 'deb-src'. Beware: You can't specify multiple
-types here and you can't download the same MetaKey form multiple types!
+types here and you can't download the same (evaluated) MetaKey from
+multiple types!
 
 After the type you can pick any valid and unique string which preferable
 refers to the file it downloads (In the example we picked 'Packages').
-This string is never shown or used.
+This string is used as identifier for the target class and accessible as
+'Created-By' e.g. in the "apt-get indextargets" output as detailed
+below.  It is also used to allow user to enable/disable targets per
+sources.list entry.
 
 All targets have three main properties you can define:
 * MetaKey: The identifier of the file to be downloaded as used in the
@@ -67,52 +65,90 @@ All targets have three main properties you can define:
   of which file is acquired exactly. Mainly used for progress reporting
   and error messages. apt will e.g. use this string in the Get/Hit/Err
   progress lines.
+  An identifier of the site accessed as seen in the sources.list (e.g.
+  "http://example.org/debian" or "file:/path/to/a/repository") is
+  automatically prefixed for this property.
+
 
 Additional optional properties:
+* DefaultEnabled: The default value is 'yes' which means that apt will
+  try to acquire this target from all sources. If set to 'no' the user
+  has to explicitly enable this target in the sources.list file with the
+  Targets option(s) – or override this value in a config file.
+* Optional: The default value is 'yes' and should be kept at this value.
+  If enabled the acquire system will skip the download if the file isn't
+  mentioned in the Release file. Otherwise this is treated as a hard
+  error and the update process fails. Note that failures while
+  downloading (e.g. 404 or hash verification errors) are failures,
+  regardless of this setting.
+* KeepCompressed: The default is the value of Acquire::GzipIndexes,
+  which defaults to false. If true, the acquire system will keep the
+  file compressed on disk rather than extract it. If your frontend can't
+  deal with compressed files transparently you have to explicitly set
+  this option to false to avoid problems with users setting the option
+  globally. On the other hand, if you set it to true or don't set it you
+  have to ensure your frontend can deal with all compressed fileformats
+  supported by apt (libapt users can e.g. use FileFd).
 * flat{MetaKey,Description}: APT supports two types of repositories:
   dists-style repositories which are the default and by far the most
   common which are named after the fact that the files are in an
-  elaborated directory structure.  In contrast a flat-style repositories
+  elaborated directory structure.  In contrast a flat-style repository
   lumps all files together in one directory.  Support for these flat
   repositories exists mainly for legacy purposes only.  It is therefore
   recommend to not set these values.
-* Optional: The default value is 'true' and should be kept at this
-  value.  If enabled the acquire system will skip the download if the
-  file isn't mentioned in the Release file. Otherwise this is treated as
-  a hard error and the update process fails.
 
 
-Note that the acquire system will automatically choose to download
-a compressed file if it is available and uncompress it for you, just as
-it will also use pdiff patching if provided by the repository and
-enabled by the user. You only have to ensure that the Release file
-contains the information about the compressed files/pdiffs to make this
-happen. NO properties have to be set to enable this.
+The acquire system will automatically choose to download a compressed
+file if it is available and uncompress it for you, just as it will also
+use PDiff patching if provided by the repository and enabled by the
+user. You only have to ensure that the Release file contains the
+information about the compressed files/PDiffs to make this happen.
+*NO* properties have to be set to enable this!
+
+
+More properties exist, but these should *NOT* be set by frontends
+requesting files. They exist for internal and end-user usage only.
+Some of these are – which are documented here only to ensure that they
+aren't accidentally used by frontends:
+* PDiffs: controls if apt will try to use PDiffs for this target.
+  Defaults to the value of Acquire::PDiffs which is true by default.
+  Can be overridden per-source by the sources.list option of the same
+  name. See the documentation for both of these for details.
+* By-Hash: controls if apt will try to use an URI constructed from
+  a hashsum of the file to download. See the documentation for config
+  option Acquire::By-Hash and sources.list option By-Hash for details.
+* CompressionTypes: The default value is a space separated list of
+  compression types supported by apt (see Acquire::CompressionTypes).
+  You can set this option to prevent apt from downloading a compression
+  type a frontend can't open transparently. This should always be
+  a temporary workaround through and a bug should be reported against
+  the frontend in question.
+
 
 # More examples
 
 The stanzas for Translation-* files as well as for Sources files would
 look like this:
 
-APT::Acquire::Targets {
+Acquire::IndexTargets {
        deb::Translations {
                MetaKey "$(COMPONENT)/i18n/Translation-$(LANGUAGE)";
                ShortDescription "Translation-$(LANGUAGE)";
-               Description "$(SITE) $(RELEASE)/$(COMPONENT) Translation-$(LANGUAGE)";
+               Description "$(RELEASE)/$(COMPONENT) Translation-$(LANGUAGE)";
 
                flatMetaKey "$(LANGUAGE)";
-               flatDescription "$(SITE) $(RELEASE) Translation-$(LANGUAGE)";
+               flatDescription "$(RELEASE) Translation-$(LANGUAGE)";
        };
 
        deb-src::Sources {
                MetaKey "$(COMPONENT)/source/Sources";
                ShortDescription "Sources";
-               Description "$(SITE) $(RELEASE)/$(COMPONENT) Sources";
+               Description "$(RELEASE)/$(COMPONENT) Sources";
 
                flatMetaKey "Sources";
-               flatDescription "$(SITE) $(RELEASE) Sources";
+               flatDescription "$(RELEASE) Sources";
 
-               Optional "false";
+               Optional "no";
        };
 };
 
@@ -121,12 +157,10 @@ APT::Acquire::Targets {
 As seen in the examples, properties can contain placeholders filled in
 by the acquire system. The following variables are known; note that
 unknown variables have no default value nor are they touched: They are
-printed literally.
+printed as-is.
 
-* $(SITE): An identifier of the site we access, e.g.
-  "http://example.org/".
 * $(RELEASE): This is usually an archive- or codename, e.g. "stable" or
-  "stretch".  Note that flat-style repositories do not have a archive-
+  "stretch".  Note that flat-style repositories do not have an archive-
   or codename per-se, so the value might very well be just "/" or so.
 * $(COMPONENT): as given in the sources.list, e.g. "main", "non-free" or
   "universe".  Note that flat-style repositories again do not really
@@ -137,3 +171,129 @@ printed literally.
   APT::Architectures (potentially modified by sources.list options),
   e.g. "amd64", "i386" or "armel" for the 'deb' type. In type 'deb-src'
   this variable has the value "source".
+* $(NATIVE_ARCHITECTURE): The architecture apt treats as the native
+  architecture for this system configured as APT::Architecture
+  defaulting to the architecture apt itself was built for.
+
+Note that while more variables might exist in the implementation, these
+are to be considered undefined and their usage strongly discouraged. If
+you have a need for other variables contact us.
+
+# Accessing files
+
+Do NOT hardcode specific file locations, names or compression types in
+your application! You will notice that the configuration options give
+you no choice over where the downloaded files will be stored. This is by
+design so multiple applications can download and use the same file
+rather than each and every one of them potentially downloads and uses
+its own copy somewhere on disk.
+
+"apt-get indextargets" can be used to get the location as well as other
+information about all files downloaded (aka: you will see Packages,
+Sources and Translation-* files here as well). Provide a line of the
+default output format as parameter to filter out all entries which do
+not have such a line. With --format, you can further more define your
+own output style. The variables are what you see in the output, just all
+uppercase and wrapped in $(), as in the configuration file.
+
+To get all the filenames of all Translation-en files you can e.g. call:
+       apt-get indextargets --format '$(FILENAME)' "Created-By: Translations" "Language: en"
+
+The line-based filtering and the formating is rather crude and feature-
+less by design: The default format is Debians standard format deb822 (in
+particular: Field names are case-insensitive and the order of fields in
+the stanza is undefined), so instead of apt reimplementing powerful
+filters and formating for this command, it is recommend to use piping
+and dedicated tools like 'grep-dctrl' if you need more than the basics
+provided.
+
+Accessing this information via libapt is done by reading the
+sources.lists (pkgSourceList), iterating over the metaIndex objects this
+creates and calling GetIndexTargets() on them. See the source code of
+"apt-get indextargets" for a complete example.
+
+Note that by default targets are not listed if they weren't downloaded.
+If you want to see all targets, you can use the --no-release-info, which
+also removes the Codename, Suite, Version, Origin, Label and Trusted
+fields from the output as these also display data which needs to be
+downloaded first and could hence be inaccurate [on the pro-side: This
+mode is faster as it doesn't require a valid binary cache to operate].
+The most notable difference perhaps is in the Filename field through: By
+default it indicates an existing file, potentially compressed (Hint:
+libapt users can use FileFd to open compressed files transparently). In
+the --no-release-info mode the indicated file doesn't need to exist and
+it will always refer to an uncompressed file, even if the index would be
+(or is) stored compressed.
+
+Remarks on fields only available in (default) --release-info mode:
+* Trusted: Denotes with a 'yes' or 'no' if the data in this file is
+  authenticated by a trust chain rooted in a trusted gpg key. You should
+  be careful with untrusted data and warn the user if you use it.
+* Codename, Suite, Version, Origin and Label are fields from the Release
+  file, are only present if they are present in the Release file and
+  contain the same data.
+
+Remarks on other available fields:
+* MetaKey, ShortDesc, Description, Site, Release: as defined
+  by the configuration and described further above.
+* Created-By: configuration entity responsible for this target
+* Target-Of: type of the sources.list entry
+* URI, Repo-URI: avoid using. Contains potentially username/password.
+  Prefer 'Site', especially for display.
+* Optional, DefaultEnabled, KeepCompressed: Decode the options of the
+  same name from the configuration.
+* Language, Architecture, Component: as defined further above, but with
+  the catch that they might be missing if they don't effect the target
+  (aka: They weren't used while evaluating the MetaKey template).
+
+Again, additional fields might be visible in certain implementations,
+but you should avoid using them and instead talk to us about a portable
+implementation.
+
+# Multiple applications requiring the same files
+
+It is highly encouraged that applications talk to each other and to us
+about which files they require. It is usually best to have a common
+package ship the configuration needed to get the files, but specific
+needs might require specific solutions. Again: talk to us.
+
+Bad things will happen if multiple frontends request the same file(s)
+via different targets, which is another reason why coordination is very
+important!
+
+# Acquiring files not mentioned in the Release file
+
+You can't. This is by design as these files couldn't be verified to not
+be modified in transit, corrupted by the download process or simple if
+they are present at all on the server, which would require apt to probe
+for them. APT did this in the past for legacy reasons, we do not intend
+to go back to these dark times.
+
+This is also why you can't request files from a different server. It
+would have the additional problem that this server might not even be
+accessible (e.g. proxy settings) or that local sources (file:/, cdrom:/)
+start requesting online files…
+
+In other words: We would be opening Pandora's box.
+
+# Acquiring files to a specific location on disk
+
+You can't by design to avoid multiple frontends requesting the same file
+to be downloaded to multiple different places on (different) disks
+(among other reasons).  See the next point for a solution if you really
+have to force a specific location by creating symlinks.
+
+# Post processing the acquired files
+
+You can't modify the files apt has downloaded as apt keeps state with
+e.g. the modification times of the files and advanced features like
+PDiffs break.
+
+You can however install an APT::Update::Post-Invoke{-Success,} hook
+script and use them to copy (modified) files to a different location.
+Use 'apt-get indextargets' (or similar) to get the filenames – do not
+look into /var/lib/apt/lists directly!
+
+Please avoid time consuming calculations in the scripts and instead just
+trigger a background task as there is little to no feedback for the user
+while hook scripts run.