-<!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.7 1999/05/23 22:55:55 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-.
unsigned long VersionCount;
unsigned long DependsCount;
unsigned long PackageFileCount;
- unsigned long MaxVerFileSize;
// Offsets
unsigned long FileList; // PackageFile
unsigned long StringList; // StringItem
+ unsigned long VerSysName; // StringTable
+ unsigned long Architecture; // StringTable
+ unsigned long MaxVerFileSize;
// Allocation pools
struct
} Pools[7];
// Package name lookup
- unsigned long HashTable[512]; // Package
+ unsigned long HashTable[2*1024]; // Package
};
</example>
<taglist>
<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.
-PackageCount is especially usefull for generating user state structures.
+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 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.
// Pointers
unsigned long Name; // Stringtable
unsigned long VersionList; // Version
- unsigned long TargetVer; // Version
unsigned long CurrentVer; // Version
- unsigned long TargetDist; // StringTable (StringItem)
unsigned long Section; // StringTable (StringItem)
// Linked lists
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>TargetVer
<tag>CurrentVer<item>
-This is an index (pointer) to the sub version that is being targeted for
-upgrading. CurrentVer is an index to the installed version, either can be
+CurrentVer is an index to the installed version, either can be
0.
-<tag>TargetDist<item>
-This indicates the target distribution. Automatic upgrades should not go
-outside of the specified dist. If it is 0 then the global target dist should
-be used. The string should be contained in the StringItem list.
-
<tag>Section<item>
This indicates the deduced section. It should be "Unknown" or the section
of the last parsed 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.
already.
<tag>Flags<item>
-Flags are some usefull indicators of the package's state.
+Flags are some useful indicators of the package's state.
</taglist>
<!-- ===================================================================== -->
<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>
unsigned long Origin; // Stringtable
unsigned long Label; // Stringtable
unsigned long Architecture; // Stringtable
+ unsigned long Site; // Stringtable
+ unsigned long IndexType; // Stringtable
unsigned long Size;
// Linked list
This is the release information. Please see the files document for a
description of what the release information means.
+<tag>Site<item>
+The site the index file was fetched from.
+
+<tag>IndexType<item>
+A string indicating what sort of index file this is.
+
<tag>Size<item>
Size is provided as a simple check to ensure that the package file has not
been altered.
<!-- ===================================================================== -->
<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
<sect>StringItem
<p>
StringItem is used for generating single instances of strings. Some things
-like Section Name are are usefull to have as unique tags. It is part of
+like Section Name are are useful to have as unique tags. It is part of
a linked list based at Header::StringList.
<example>
struct StringItem
#define pkgDEP_Recommends 4
#define pkgDEP_Conflicts 5
#define pkgDEP_Replaces 6
+#define pkgDEP_Breaks 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