Version 3.1.3
Copyright © 1998 Jason Gunthorpe
License Notice
"APT" and this document are free software; you can redistribute them and/or modify them under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. |
For more details, on Debian systems, see the file /usr/share/common-licenses/GPL for the full license. |
Abstract
This document describes the interface that APT uses to the archive access methods.
Table of Contents
Table of Contents
The APT method interface allows APT to acquire archive files (.deb), index files (Packages, Release, Mirrors) and source files (.tar.gz, .diff). It is a general, extensible system designed to satisfy all of these requirements: |
|
Initial releases of APT (0.1.x) used a completely different method interface that only supported the first 6 items. This new interface deals with the remainder. |
Several terms are used through out the document, they have specific meanings which may not be immediately evident. To clarify they are summarized here. |
|
Table of Contents
All methods operate as a sub process of a main controlling parent. 3 FD's are opened for use by the method allowing two way communication and emergency error reporting. The FD's correspond to the well known unix FD's, stdin, stdout and stderr. |
Through operation of the method communication is done via http style plain text. Specifically RFC-822 (like the Package file) fields are used to describe items and a numeric-like header is used to indicate what is happening. Each of these distinct communication messages should be sent quickly and without pause. |
In some instances APT may pre-invoke a method to allow things like file URI's to determine how many files are available locally. |
The first line of each message is called the message header. The first 3 digits (called the Status Code) have the usual meaning found in the http protocol. 1xx is informational, 2xx is successful and 4xx is failure. The 6xx series is used to specify things sent to the method. After the status code is an informational string provided for visual debugging. |
|
Only the 6xx series of status codes is sent TO the method. Furthermore the method may not emit status codes in the 6xx range. The Codes 351, 402 and 403 require that the method continue reading all other 6xx codes until the proper 600/602/603 code is received. This means the method must be capable of handling an unlimited number of 600 messages. |
The flow of messages starts with the method sending out a 100 Capabilities and APT sending out a 601 Configuration. After that APT begins sending 600 URI Acquire and the method sends out 200 URI Start, 201 URI Done or 400 URI Failure. No synchronization is performed, it is expected that APT will send 600 URI Acquire messages at -any- time and that the method should queue the messages. This allows methods like http to pipeline requests to the remote server. It should be noted however that APT will buffer messages so it is not necessary for the method to be constantly ready to receive them. |
The following is a short index of the header fields that are supported |
|
This is a list of which headers each status code can use |
|
The methods supplied by the stock apt are: |
|
The two internal methods, copy and gzip, are used by the acquire code to parallelize and simplify the automatic decompression of package files as well as copying package files around the file system. Both methods can be seen to act the same except that one decompresses on the fly. APT uses them by generating a copy URI that is formed identically to a file URI. The destination file is send as normal. The method then takes the file specified by the URI and writes it to the destination file. A typical set of operations may be: |
http://foo.com/Packages.gz -> /bar/Packages.gz gzip:/bar/Packages.gz -> /bar/Packages.decomp rename Packages.decomp to /final/Packages |
The http method implements a fully featured HTTP/1.1 client that supports deep pipelining and reget. It works best when coupled with an apache 1.3 server. The file method simply generates failures or success responses with the filename field set to the proper location. The cdrom method acts the same except that it checks that the mount point has a valid cdrom in it. It does this by (effectively) computing a md5 hash of 'ls -l' on the mountpoint. |