-<!doctype debiandoc system>
<!-- -*- mode: sgml; mode: fold -*- -->
+<!doctype debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN">
<book>
<title>APT Cache File Format</title>
<author>Jason Gunthorpe <email>jgg@debian.org</email></author>
-<version>$Id: cache.sgml,v 1.8 2001/02/20 07:03:17 jgg Exp $</version>
+<version>$Id: cache.sgml,v 1.11 2003/02/12 15:05:44 doogie Exp $</version>
<abstract>
This document describes the complete implementation and format of the APT
<p>
For more details, on Debian GNU/Linux systems, see the file
-/usr/doc/copyright/GPL for the full license.
+/usr/share/common-licenses/GPL for the full license.
</copyright>
<toc sect>
file.
<p>
-Please understand, this is designed as a -CACHE FILE- it is not ment to be
-used on any system other than the one it was created for. It is not ment to
-be authoritative either, ie if a system crash or software failure occures it
-must be perfectly acceptable for the cache file to be in an inconsistant
+Please understand, this is designed as a -CACHE FILE- it is not meant to be
+used on any system other than the one it was created for. It is not meant to
+be authoritative either, i.e. if a system crash or software failure occurs it
+must be perfectly acceptable for the cache file to be in an inconsistent
state. Furthermore at any time the cache file may be erased without losing
any information.
<p>
To keep memory use down the cache file only contains often used fields and
-fields that are inexepensive to store, the Package file has a full list of
+fields that are inexpensive to store, the Package file has a full list of
fields. Also the client may assume that all items are perfectly valid and
need not perform checks against their correctness. Removal of information
from the cache is possible, but blanks will be left in the file, and
by taking the index, multiplying it by the type size and then adding
it to the start address of the memory block. This sounds complex, but
in C it is a single array dereference. Because all items are aligned to
-their size and indexs are stored as multiples of the size of the structure
+their size and indexes are stored as multiples of the size of the structure
the format is immediately portable to all possible architectures - BUT the
generated files are -NOT-.
<tag>VerFileSz
<tag>ProvidesSz<item>
*Sz contains the sizeof() that particular structure. It is used as an
-extra consistancy check on the structure of the file.
+extra consistency check on the structure of the file.
If any of the size values do not exactly match what the client expects then
the client should refuse the load the file.
<tag>VersionCount
<tag>DependsCount
<tag>PackageFileCount<item>
-These indicate the number of each structure contianed in the cache.
+These indicate the number of each structure contained in the cache.
PackageCount is especially useful for generating user state structures.
See Package::Id for more info.
<tag>VerSysName<item>
-String representing the versiong system used for this cache
+String representing the version system used for this cache
<tag>Architecture<item>
Architecture the cache was built against.
<tag>MaxVerFileSize<item>
The maximum size of a raw entry from the original Package file
-(ie VerFile::Size) is stored here.
+(i.e. VerFile::Size) is stored here.
<tag>FileList<item>
This contains the index of the first PackageFile structure. The PackageFile
-structures are singely linked lists that represent all package files that
+structures are singly linked lists that represent all package files that
have been merged into the cache.
<tag>StringList<item>
</example>
<p>
By iterating over each entry in the hash table it is possible to iterate over
-the entire list of packages. Hash Collisions are handled with a singely linked
+the entire list of packages. Hash Collisions are handled with a singly linked
list of packages based at the hash item. The linked list contains only
-packages that macth the hashing function.
+packages that match the hashing function.
</taglist>
<!-- }}} -->
<!-- ===================================================================== -->
<sect>Package
<p>
-This contians information for a single unique package. There can be any
+This contains information for a single unique package. There can be any
number of versions of a given package. Package exists in a singly
linked list of package records starting at the hash index of the name in
the Header->HashTable.
Name of the package.
<tag>VersionList<item>
-Base of a singely linked list of version structures. Each structure
+Base of a singly linked list of version structures. Each structure
represents a unique version of the package. The version structures
contain links into PackageFile and the original text file as well as
-detailed infromation about the size and dependencies of the specific
+detailed information about the size and dependencies of the specific
package. In this way multiple versions of a package can be cleanly handled
-by the system. Furthermore, this linked list is guarenteed to be sorted
+by the system. Furthermore, this linked list is guaranteed to be sorted
from Highest version to lowest version with no duplicate entries.
<tag>CurrentVer<item>
<tag>SelectedState
<tag>InstState
<tag>CurrentState<item>
-These corrispond to the 3 items in the Status field found in the status
+These correspond to the 3 items in the Status field found in the status
file. See the section on defines for the possible values.
<p>
SelectedState is the state that the user wishes the package to be
in.
<p>
InstState is the installation state of the package. This normally
-should be Ok, but if the installation had an accident it may be otherwise.
+should be OK, but if the installation had an accident it may be otherwise.
<p>
CurrentState indicates if the package is installed, partially installed or
not installed.
<!-- ===================================================================== -->
<sect>PackageFile
<p>
-This contians information for a single package file. Package files are
+This contains information for a single package file. Package files are
referenced by Version structures. This is a singly linked list based from
Header.FileList
<example>
<!-- ===================================================================== -->
<sect>Version
<p>
-This contians the information for a single version of a package. This is a
-singley linked list based from Package.Versionlist.
+This contains the information for a single version of a package. This is a
+single linked list based from Package.Versionlist.
<p>
The version list is always sorted from highest version to lowest version by
<tag>Size
<tag>InstalledSize<item>
-The archive size for this version. For debian this is the size of the .deb
+The archive size for this version. For Debian this is the size of the .deb
file. Installed size is the uncompressed size for this version
<tag>Hash<item>
This is a characteristic value representing this package. No two packages
-in existance should have the same VerStr and Hash with different contents.
+in existence should have the same VerStr and Hash with different contents.
<tag>ID<item>
See Package::ID.
Dependency contains the information for a single dependency record. The records
are split up like this to ease processing by the client. The base of list
linked list is Version.DependsList. All forms of dependencies are recorded
-here including Conflicts, Suggests and Recommends.
+here including Conflicts, Breaks, Suggests and Recommends.
<p>
Multiple depends on the same package must be grouped together in
#define pkgDEP_Recommends 4
#define pkgDEP_Conflicts 5
#define pkgDEP_Replaces 6
+#define pkgDEP_Breaks 8
</example>
</sect1>
#define pkgSTATE_HalfInstalled 4
#define pkgSTATE_ConfigFiles 5
#define pkgSTATE_Installed 6
+#define pkgSTATE_TriggersAwaited 7
+#define pkgSTATE_TriggersPending 8
</example>
</sect1>
<p>
Different section names on different versions is supported, but I
-do not expect to use it. To simplify the GUI it will mearly use the section
+do not expect to use it. To simplify the GUI it will merely use the section
in the Package structure. This should be okay as I hope sections do not change
much.
<p>
Caching of the info/*.list is an excellent place to start, by generating all
the list files into a tree structure and reverse linking them to the package
-structures in the main cache file major speed gains in dpkg might be achived.
+structures in the main cache file major speed gains in dpkg might be achieved.
<!-- }}} -->
projects / apt.git / blobdiff