+ 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 front-ends 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 front-ends 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.
projects / apt.git / blobdiff