cache.sgml 27 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806
  1. <!doctype debiandoc system>
  2. <!-- -*- mode: sgml; mode: fold -*- -->
  3. <book>
  4. <title>APT Cache File Format</title>
  5. <author>Jason Gunthorpe <email>jgg@debian.org</email></author>
  6. <version>$Id: cache.sgml,v 1.5 1998/12/14 08:23:10 jgg Exp $</version>
  7. <abstract>
  8. This document describes the complete implementation and format of the APT
  9. Cache file. The APT Cache file is a way for APT to parse and store a
  10. large number of package files for display in the UI. It's primary design
  11. goal is to make display of a single package in the tree very fast by
  12. pre-linking important things like dependencies and provides.
  13. The specification doubles as documentation for one of the in-memory
  14. structures used by the package library and the APT GUI.
  15. </abstract>
  16. <copyright>
  17. Copyright &copy; Jason Gunthorpe, 1997-1998.
  18. <p>
  19. APT and this document are free software; you can redistribute them and/or
  20. modify them under the terms of the GNU General Public License as published
  21. by the Free Software Foundation; either version 2 of the License, or (at your
  22. option) any later version.
  23. <p>
  24. For more details, on Debian GNU/Linux systems, see the file
  25. /usr/doc/copyright/GPL for the full license.
  26. </copyright>
  27. <toc sect>
  28. <chapt>Introduction
  29. <!-- Purpose {{{ -->
  30. <!-- ===================================================================== -->
  31. <sect>Purpose
  32. <p>
  33. This document describes the implementation of an architecture
  34. dependent binary cache file. The goal of this cache file is two fold,
  35. firstly to speed loading and processing of the package file array and
  36. secondly to reduce memory consumption of the package file array.
  37. <p>
  38. The implementation is aimed at an environment with many primary package
  39. files, for instance someone that has a Package file for their CD-ROM, a
  40. Package file for the latest version of the distribution on the CD-ROM and a
  41. package file for the development version. Always present is the information
  42. contained in the status file which might be considered a separate package
  43. file.
  44. <p>
  45. Please understand, this is designed as a -CACHE FILE- it is not ment to be
  46. used on any system other than the one it was created for. It is not ment to
  47. be authoritative either, ie if a system crash or software failure occures it
  48. must be perfectly acceptable for the cache file to be in an inconsistant
  49. state. Furthermore at any time the cache file may be erased without losing
  50. any information.
  51. <p>
  52. Also the structures and storage layout is optimized for use by the APT
  53. GUI and may not be suitable for all purposes. However it should be possible
  54. to extend it with associate cache files that contain other information.
  55. <p>
  56. To keep memory use down the cache file only contains often used fields and
  57. fields that are inexepensive to store, the Package file has a full list of
  58. fields. Also the client may assume that all items are perfectly valid and
  59. need not perform checks against their correctness. Removal of information
  60. from the cache is possible, but blanks will be left in the file, and
  61. unused strings will also be present. The recommended implementation is to
  62. simply rebuild the cache each time any of the data files change. It is
  63. possible to add a new package file to the cache without any negative side
  64. effects.
  65. <sect1>Note on Pointer access
  66. <p>
  67. Every item in every structure is stored as the index to that structure.
  68. What this means is that once the files is mmaped every data access has to
  69. go through a fixup stage to get a real memory pointer. This is done
  70. by taking the index, multiplying it by the type size and then adding
  71. it to the start address of the memory block. This sounds complex, but
  72. in C it is a single array dereference. Because all items are aligned to
  73. their size and indexs are stored as multiples of the size of the structure
  74. the format is immediately portable to all possible architectures - BUT the
  75. generated files are -NOT-.
  76. <p>
  77. This scheme allows code like this to be written:
  78. <example>
  79. void *Map = mmap(...);
  80. Package *PkgList = (Package *)Map;
  81. Header *Head = (Header *)Map;
  82. char *Strings = (char *)Map;
  83. cout << (Strings + PkgList[Head->HashTable[0]]->Name) << endl;
  84. </example>
  85. <p>
  86. Notice the lack of casting or multiplication. The net result is to return
  87. the name of the first package in the first hash bucket, without error
  88. checks.
  89. <p>
  90. The generator uses allocation pools to group similarly sized structures in
  91. large blocks to eliminate any alignment overhead. The generator also
  92. assures that no structures overlap and all indexes are unique. Although
  93. at first glance it may seem like there is the potential for two structures
  94. to exist at the same point the generator never allows this to happen.
  95. (See the discussion of free space pools)
  96. <!-- }}} -->
  97. <chapt>Structures
  98. <!-- Header {{{ -->
  99. <!-- ===================================================================== -->
  100. <sect>Header
  101. <p>
  102. This is the first item in the file.
  103. <example>
  104. struct Header
  105. {
  106. // Signature information
  107. unsigned long Signature;
  108. short MajorVersion;
  109. short MinorVersion;
  110. bool Dirty;
  111. // Size of structure values
  112. unsigned short HeaderSz;
  113. unsigned short PackageSz;
  114. unsigned short PackageFileSz;
  115. unsigned short VersionSz;
  116. unsigned short DependencySz;
  117. unsigned short ProvidesSz;
  118. unsigned short VerFileSz;
  119. // Structure counts
  120. unsigned long PackageCount;
  121. unsigned long VersionCount;
  122. unsigned long DependsCount;
  123. unsigned long PackageFileCount;
  124. unsigned long MaxVerFileSize;
  125. // Offsets
  126. unsigned long FileList; // PackageFile
  127. unsigned long StringList; // StringItem
  128. // Allocation pools
  129. struct
  130. {
  131. unsigned long ItemSize;
  132. unsigned long Start;
  133. unsigned long Count;
  134. } Pools[7];
  135. // Package name lookup
  136. unsigned long HashTable[512]; // Package
  137. };
  138. </example>
  139. <taglist>
  140. <tag>Signature<item>
  141. This must contain the hex value 0x98FE76DC which is designed to verify
  142. that the system loading the image has the same byte order and byte size as
  143. the system saving the image
  144. <tag>MajorVersion
  145. <tag>MinorVersion<item>
  146. These contain the version of the cache file, currently 0.2.
  147. <tag>Dirty<item>
  148. Dirty is true if the cache file was opened for reading, the client expects
  149. to have written things to it and have not fully synced it. The file should
  150. be erased and rebuilt if it is true.
  151. <tag>HeaderSz
  152. <tag>PackageSz
  153. <tag>PackageFileSz
  154. <tag>VersionSz
  155. <tag>DependencySz
  156. <tag>VerFileSz
  157. <tag>ProvidesSz<item>
  158. *Sz contains the sizeof() that particular structure. It is used as an
  159. extra consistancy check on the structure of the file.
  160. If any of the size values do not exactly match what the client expects then
  161. the client should refuse the load the file.
  162. <tag>PackageCount
  163. <tag>VersionCount
  164. <tag>DependsCount
  165. <tag>PackageFileCount<item>
  166. These indicate the number of each structure contianed in the cache.
  167. PackageCount is especially usefull for generating user state structures.
  168. See Package::Id for more info.
  169. <tag>MaxVerFileSize<item>
  170. The maximum size of a raw entry from the original Package file
  171. (ie VerFile::Size) is stored here.
  172. <tag>FileList<item>
  173. This contains the index of the first PackageFile structure. The PackageFile
  174. structures are singely linked lists that represent all package files that
  175. have been merged into the cache.
  176. <tag>StringList<item>
  177. This contains a list of all the unique strings (string item type strings) in
  178. the cache. The parser reads this list into memory so it can match strings
  179. against it.
  180. <tag>Pools<item>
  181. The Pool structures manage the allocation pools that the generator uses.
  182. Start indicates the first byte of the pool, Count is the number of objects
  183. remaining in the pool and ItemSize is the structure size (alignment factor)
  184. of the pool. An ItemSize of 0 indicates the pool is empty. There should be
  185. the same number of pools as there are structure types. The generator
  186. stores this information so future additions can make use of any unused pool
  187. blocks.
  188. <tag>HashTable<item>
  189. HashTable is a hash table that provides indexing for all of the packages.
  190. Each package name is inserted into the hash table using the following has
  191. function:
  192. <example>
  193. unsigned long Hash(string Str)
  194. {
  195. unsigned long Hash = 0;
  196. for (const char *I = Str.begin(); I != Str.end(); I++)
  197. Hash += *I * ((Str.end() - I + 1));
  198. return Hash % _count(Head.HashTable);
  199. }
  200. </example>
  201. <p>
  202. By iterating over each entry in the hash table it is possible to iterate over
  203. the entire list of packages. Hash Collisions are handled with a singely linked
  204. list of packages based at the hash item. The linked list contains only
  205. packages that macth the hashing function.
  206. </taglist>
  207. <!-- }}} -->
  208. <!-- Package {{{ -->
  209. <!-- ===================================================================== -->
  210. <sect>Package
  211. <p>
  212. This contians information for a single unique package. There can be any
  213. number of versions of a given package. Package exists in a singly
  214. linked list of package records starting at the hash index of the name in
  215. the Header->HashTable.
  216. <example>
  217. struct Pacakge
  218. {
  219. // Pointers
  220. unsigned long Name; // Stringtable
  221. unsigned long VersionList; // Version
  222. unsigned long TargetVer; // Version
  223. unsigned long CurrentVer; // Version
  224. unsigned long TargetDist; // StringTable (StringItem)
  225. unsigned long Section; // StringTable (StringItem)
  226. // Linked lists
  227. unsigned long NextPackage; // Package
  228. unsigned long RevDepends; // Dependency
  229. unsigned long ProvidesList; // Provides
  230. // Install/Remove/Purge etc
  231. unsigned char SelectedState; // What
  232. unsigned char InstState; // Flags
  233. unsigned char CurrentState; // State
  234. // Unique ID for this pkg
  235. unsigned short ID;
  236. unsigned long Flags;
  237. };
  238. </example>
  239. <taglist>
  240. <tag>Name<item>
  241. Name of the package.
  242. <tag>VersionList<item>
  243. Base of a singely linked list of version structures. Each structure
  244. represents a unique version of the package. The version structures
  245. contain links into PackageFile and the original text file as well as
  246. detailed infromation about the size and dependencies of the specific
  247. package. In this way multiple versions of a package can be cleanly handled
  248. by the system. Furthermore, this linked list is guarenteed to be sorted
  249. from Highest version to lowest version with no duplicate entries.
  250. <tag>TargetVer
  251. <tag>CurrentVer<item>
  252. This is an index (pointer) to the sub version that is being targeted for
  253. upgrading. CurrentVer is an index to the installed version, either can be
  254. 0.
  255. <tag>TargetDist<item>
  256. This indicates the target distribution. Automatic upgrades should not go
  257. outside of the specified dist. If it is 0 then the global target dist should
  258. be used. The string should be contained in the StringItem list.
  259. <tag>Section<item>
  260. This indicates the deduced section. It should be "Unknown" or the section
  261. of the last parsed item.
  262. <tag>NextPackage<item>
  263. Next link in this hash item. This linked list is based at Header.HashTable
  264. and contains only packages with the same hash value.
  265. <tag>RevDepends<item>
  266. Reverse Depends is a linked list of all dependencies linked to this package.
  267. <tag>ProvidesList<item>
  268. This is a linked list of all provides for this package name.
  269. <tag>SelectedState
  270. <tag>InstState
  271. <tag>CurrentState<item>
  272. These corrispond to the 3 items in the Status field found in the status
  273. file. See the section on defines for the possible values.
  274. <p>
  275. SelectedState is the state that the user wishes the package to be
  276. in.
  277. <p>
  278. InstState is the installation state of the package. This normally
  279. should be Ok, but if the installation had an accident it may be otherwise.
  280. <p>
  281. CurrentState indicates if the package is installed, partially installed or
  282. not installed.
  283. <tag>ID<item>
  284. ID is a value from 0 to Header->PackageCount. It is a unique value assigned
  285. by the generator. This allows clients to create an array of size PackageCount
  286. and use it to store state information for the package map. For instance the
  287. status file emitter uses this to track which packages have been emitted
  288. already.
  289. <tag>Flags<item>
  290. Flags are some usefull indicators of the package's state.
  291. </taglist>
  292. <!-- }}} -->
  293. <!-- PackageFile {{{ -->
  294. <!-- ===================================================================== -->
  295. <sect>PackageFile
  296. <p>
  297. This contians information for a single package file. Package files are
  298. referenced by Version structures. This is a singly linked list based from
  299. Header.FileList
  300. <example>
  301. struct PackageFile
  302. {
  303. // Names
  304. unsigned long FileName; // Stringtable
  305. unsigned long Archive; // Stringtable
  306. unsigned long Component; // Stringtable
  307. unsigned long Version; // Stringtable
  308. unsigned long Origin; // Stringtable
  309. unsigned long Label; // Stringtable
  310. unsigned long Architecture; // Stringtable
  311. unsigned long Size;
  312. // Linked list
  313. unsigned long NextFile; // PackageFile
  314. unsigned short ID;
  315. unsigned long Flags;
  316. time_t mtime; // Modification time
  317. };
  318. </example>
  319. <taglist>
  320. <tag>FileName<item>
  321. Refers the the physical disk file that this PacakgeFile represents.
  322. <tag>Archive
  323. <tag>Component
  324. <tag>Version
  325. <tag>Origin
  326. <tag>Label
  327. <tag>Architecture
  328. <tag>NotAutomatic<item>
  329. This is the release information. Please see the files document for a
  330. description of what the release information means.
  331. <tag>Size<item>
  332. Size is provided as a simple check to ensure that the package file has not
  333. been altered.
  334. <tag>ID<item>
  335. See Package::ID.
  336. <tag>Flags<item>
  337. Provides some flags for the PackageFile, see the section on defines.
  338. <tag>mtime<item>
  339. Modification time for the file at time of cache generation.
  340. </taglist>
  341. <!-- }}} -->
  342. <!-- Version {{{ -->
  343. <!-- ===================================================================== -->
  344. <sect>Version
  345. <p>
  346. This contians the information for a single version of a package. This is a
  347. singley linked list based from Package.Versionlist.
  348. <p>
  349. The version list is always sorted from highest version to lowest version by
  350. the generator. Also there may not be any duplicate entries in the list (same
  351. VerStr).
  352. <example>
  353. struct Version
  354. {
  355. unsigned long VerStr; // Stringtable
  356. unsigned long Section; // StringTable (StringItem)
  357. // Lists
  358. unsigned long FileList; // VerFile
  359. unsigned long NextVer; // Version
  360. unsigned long DependsList; // Dependency
  361. unsigned long ParentPkg; // Package
  362. unsigned long ProvidesList; // Provides
  363. unsigned long Size;
  364. unsigned long InstalledSize;
  365. unsigned short ID;
  366. unsigned char Priority;
  367. };
  368. </example>
  369. <taglist>
  370. <tag>VerStr<item>
  371. This is the complete version string.
  372. <tag>FileList<item>
  373. References the all the PackageFile's that this version came out of. FileList
  374. can be used to determine what distribution(s) the Version applies to. If
  375. FileList is 0 then this is a blank version. The structure should also have
  376. a 0 in all other fields excluding VerStr and Possibly NextVer.
  377. <tag>Section<item>
  378. This string indicates which section it is part of. The string should be
  379. contained in the StringItem list.
  380. <tag>NextVer<item>
  381. Next step in the linked list.
  382. <tag>DependsList<item>
  383. This is the base of the dependency list.
  384. <tag>ParentPkg<item>
  385. This links the version to the owning package, allowing reverse dependencies
  386. to determine the package.
  387. <tag>ProvidesList<item>
  388. Head of the linked list of Provides::NextPkgProv, forward provides.
  389. <tag>Size
  390. <tag>InstalledSize<item>
  391. The archive size for this version. For debian this is the size of the .deb
  392. file. Installed size is the uncompressed size for this version
  393. <tag>ID<item>
  394. See Package::ID.
  395. <tag>Priority<item>
  396. This is the parsed priority value of the package.
  397. </taglist>
  398. <!-- }}} -->
  399. <!-- Dependency {{{ -->
  400. <!-- ===================================================================== -->
  401. <sect>Dependency
  402. <p>
  403. Dependency contains the information for a single dependency record. The records
  404. are split up like this to ease processing by the client. The base of list
  405. linked list is Version.DependsList. All forms of dependencies are recorded
  406. here including Conflicts, Suggests and Recommends.
  407. <p>
  408. Multiple depends on the same package must be grouped together in
  409. the Dependency lists. Clients should assume this is always true.
  410. <example>
  411. struct Dependency
  412. {
  413. unsigned long Version; // Stringtable
  414. unsigned long Package; // Package
  415. unsigned long NextDepends; // Dependency
  416. unsigned long NextRevDepends; // Reverse dependency linking
  417. unsigned long ParentVer; // Upwards parent version link
  418. // Specific types of depends
  419. unsigned char Type;
  420. unsigned char CompareOp;
  421. unsigned short ID;
  422. };
  423. </example>
  424. <taglist>
  425. <tag>Version<item>
  426. The string form of the version that the dependency is applied against.
  427. <tag>Package<item>
  428. The index of the package file this depends applies to. If the package file
  429. does not already exist when the dependency is inserted a blank one (no
  430. version records) should be created.
  431. <tag>NextDepends<item>
  432. Linked list based off a Version structure of all the dependencies in that
  433. version.
  434. <tag>NextRevDepends<item>
  435. Reverse dependency linking, based off a Package structure. This linked list
  436. is a list of all packages that have a depends line for a given package.
  437. <tag>ParentVer<item>
  438. Parent version linking, allows the reverse dependency list to link
  439. back to the version and package that the dependency are for.
  440. <tag>Type<item>
  441. Describes weather it is depends, predepends, recommends, suggests, etc.
  442. <tag>CompareOp<item>
  443. Describes the comparison operator specified on the depends line. If the high
  444. bit is set then it is a logical or with the previous record.
  445. <tag>ID<item>
  446. See Package::ID.
  447. </taglist>
  448. <!-- }}} -->
  449. <!-- Provides {{{ -->
  450. <!-- ===================================================================== -->
  451. <sect>Provides
  452. <p>
  453. Provides handles virtual packages. When a Provides: line is encountered
  454. a new provides record is added associating the package with a virtual
  455. package name. The provides structures are linked off the package structures.
  456. This simplifies the analysis of dependencies and other aspects A provides
  457. refers to a specific version of a specific package, not all versions need to
  458. provide that provides.
  459. <p>
  460. There is a linked list of provided package names started from each
  461. version that provides packages. This is the forwards provides mechanism.
  462. <example>
  463. struct Provides
  464. {
  465. unsigned long ParentPkg; // Package
  466. unsigned long Version; // Version
  467. unsigned long ProvideVersion; // Stringtable
  468. unsigned long NextProvides; // Provides
  469. unsigned long NextPkgProv; // Provides
  470. };
  471. </example>
  472. <taglist>
  473. <tag>ParentPkg<item>
  474. The index of the package that head of this linked list is in. ParentPkg->Name
  475. is the name of the provides.
  476. <tag>Version<item>
  477. The index of the version this provide line applies to.
  478. <tag>ProvideVersion<item>
  479. Each provides can specify a version in the provides line. This version allows
  480. dependencies to depend on specific versions of a Provides, as well as allowing
  481. Provides to override existing packages. This is experimental.
  482. <tag>NextProvides<item>
  483. Next link in the singly linked list of provides (based off package)
  484. <tag>NextPkgProv<item>
  485. Next link in the singly linked list of provides for 'Version'.
  486. </taglist>
  487. <!-- }}} -->
  488. <!-- VerFile {{{ -->
  489. <!-- ===================================================================== -->
  490. <sect>VerFile
  491. <p>
  492. VerFile associates a version with a PackageFile, this allows a full
  493. description of all Versions in all files (and hence all sources) under
  494. consideration.
  495. <example>
  496. struct pkgCache::VerFile
  497. {
  498. unsigned long File; // PackageFile
  499. unsigned long NextFile; // PkgVerFile
  500. unsigned long Offset;
  501. unsigned short Size;
  502. }
  503. </example>
  504. <taglist>
  505. <tag>File<item>
  506. The index of the package file that this version was found in.
  507. <tag>NextFile<item>
  508. The next step in the linked list.
  509. <tag>Offset
  510. <tag>Size<item>
  511. These describe the exact position in the package file for the section from
  512. this version.
  513. </taglist>
  514. <!-- }}} -->
  515. <!-- StringItem {{{ -->
  516. <!-- ===================================================================== -->
  517. <sect>StringItem
  518. <p>
  519. StringItem is used for generating single instances of strings. Some things
  520. like Section Name are are usefull to have as unique tags. It is part of
  521. a linked list based at Header::StringList.
  522. <example>
  523. struct StringItem
  524. {
  525. unsigned long String; // Stringtable
  526. unsigned long NextItem; // StringItem
  527. };
  528. </example>
  529. <taglist>
  530. <tag>String<item>
  531. The string this refers to.
  532. <tag>NextItem<item>
  533. Next link in the chain.
  534. </taglist>
  535. <!-- }}} -->
  536. <!-- StringTable {{{ -->
  537. <!-- ===================================================================== -->
  538. <sect>StringTable
  539. <p>
  540. All strings are simply inlined any place in the file that is natural for the
  541. writer. The client should make no assumptions about the positioning of
  542. strings. All stringtable values point to a byte offset from the start of the
  543. file that a null terminated string will begin.
  544. <!-- }}} -->
  545. <!-- Defines {{{ -->
  546. <!-- ===================================================================== -->
  547. <sect>Defines
  548. <p>
  549. Several structures use variables to indicate things. Here is a list of all
  550. of them.
  551. <sect1>Definitions for Dependency::Type
  552. <p>
  553. <example>
  554. #define pkgDEP_Depends 1
  555. #define pkgDEP_PreDepends 2
  556. #define pkgDEP_Suggests 3
  557. #define pkgDEP_Recommends 4
  558. #define pkgDEP_Conflicts 5
  559. #define pkgDEP_Replaces 6
  560. </example>
  561. </sect1>
  562. <sect1>Definitions for Dependency::CompareOp
  563. <p>
  564. <example>
  565. #define pkgOP_OR 0x10
  566. #define pkgOP_LESSEQ 0x1
  567. #define pkgOP_GREATEREQ 0x2
  568. #define pkgOP_LESS 0x3
  569. #define pkgOP_GREATER 0x4
  570. #define pkgOP_EQUALS 0x5
  571. </example>
  572. The lower 4 bits are used to indicate what operator is being specified and
  573. the upper 4 bits are flags. pkgOP_OR indicates that the next package is
  574. or'd with the current package.
  575. </sect1>
  576. <sect1>Definitions for Package::SelectedState
  577. <p>
  578. <example>
  579. #define pkgSTATE_Unkown 0
  580. #define pkgSTATE_Install 1
  581. #define pkgSTATE_Hold 2
  582. #define pkgSTATE_DeInstall 3
  583. #define pkgSTATE_Purge 4
  584. </example>
  585. </sect1>
  586. <sect1>Definitions for Package::InstState
  587. <p>
  588. <example>
  589. #define pkgSTATE_Ok 0
  590. #define pkgSTATE_ReInstReq 1
  591. #define pkgSTATE_Hold 2
  592. #define pkgSTATE_HoldReInstReq 3
  593. </example>
  594. </sect1>
  595. <sect1>Definitions for Package::CurrentState
  596. <p>
  597. <example>
  598. #define pkgSTATE_NotInstalled 0
  599. #define pkgSTATE_UnPacked 1
  600. #define pkgSTATE_HalfConfigured 2
  601. #define pkgSTATE_UnInstalled 3
  602. #define pkgSTATE_HalfInstalled 4
  603. #define pkgSTATE_ConfigFiles 5
  604. #define pkgSTATE_Installed 6
  605. </example>
  606. </sect1>
  607. <sect1>Definitions for Package::Flags
  608. <p>
  609. <example>
  610. #define pkgFLAG_Auto (1 << 0)
  611. #define pkgFLAG_New (1 << 1)
  612. #define pkgFLAG_Obsolete (1 << 2)
  613. #define pkgFLAG_Essential (1 << 3)
  614. #define pkgFLAG_ImmediateConf (1 << 4)
  615. </example>
  616. </sect1>
  617. <sect1>Definitions for Version::Priority
  618. <p>
  619. Zero is used for unparsable or absent Priority fields.
  620. <example>
  621. #define pkgPRIO_Important 1
  622. #define pkgPRIO_Required 2
  623. #define pkgPRIO_Standard 3
  624. #define pkgPRIO_Optional 4
  625. #define pkgPRIO_Extra 5
  626. </example>
  627. </sect1>
  628. <sect1>Definitions for PackageFile::Flags
  629. <p>
  630. <example>
  631. #define pkgFLAG_NotSource (1 << 0)
  632. #define pkgFLAG_NotAutomatic (1 << 1)
  633. </example>
  634. </sect1>
  635. <!-- }}} -->
  636. <chapt>Notes on the Generator
  637. <!-- Notes on the Generator {{{ -->
  638. <!-- ===================================================================== -->
  639. <p>
  640. The pkgCache::MergePackageFile function is currently the only generator of
  641. the cache file. It implements a conversion from the normal textual package
  642. file into the cache file.
  643. <p>
  644. The generator assumes any package declaration with a
  645. Status: line is a 'Status of the package' type of package declaration.
  646. A Package with a Target-Version field should also really have a status field.
  647. The processing of a Target-Version field can create a place-holder Version
  648. structure that is empty to refer to the specified version (See Version
  649. for info on what a empty Version looks like). The Target-Version syntax
  650. allows the specification of a specific version and a target distribution.
  651. <p>
  652. Different section names on different versions is supported, but I
  653. do not expect to use it. To simplify the GUI it will mearly use the section
  654. in the Package structure. This should be okay as I hope sections do not change
  655. much.
  656. <p>
  657. The generator goes through a number of post processing steps after producing
  658. a disk file. It sorts all of the version lists to be in descending order
  659. and then generates the reverse dependency lists for all of the packages.
  660. ID numbers and count values are also generated in the post processing step.
  661. <p>
  662. It is possible to extend many of the structures in the cache with extra data.
  663. This is done by using the ID member. ID will be a unique number from 0 to
  664. Header->??Count. For example
  665. <example>
  666. struct MyPkgData;
  667. MyPkgData *Data = new MyPkgData[Header->PackageCount];
  668. Data[Package->ID]->Item = 0;
  669. </example>
  670. This provides a one way reference between package structures and user data. To
  671. get a two way reference would require a member inside the MyPkgData structure.
  672. <p>
  673. The generators use of free space pools tend to make the package file quite
  674. large, and quite full of blank space. This could be fixed with sparse files.
  675. <!-- }}} -->
  676. <chapt>Future Directions
  677. <!-- Future Directions {{{ -->
  678. <!-- ===================================================================== -->
  679. <p>
  680. Some good directions to take the cache file is into a cache directory that
  681. contains many associated caches that cache other important bits of
  682. information. (/var/cache/apt, FHS2)
  683. <p>
  684. Caching of the info/*.list is an excellent place to start, by generating all
  685. the list files into a tree structure and reverse linking them to the package
  686. structures in the main cache file major speed gains in dpkg might be achived.
  687. <!-- }}} -->
  688. </book>