summaryrefslogtreecommitdiff
path: root/doc/cache.sgml
blob: aea5a45c35c580199117872310044143e0fe5c89 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
<!-- -*- 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.11 2003/02/12 15:05:44 doogie Exp $</version>

<abstract>
This document describes the complete implementation and format of the APT
Cache file. The APT Cache file is a way for APT to parse and store a 
large number of package files for display in the UI. It's primary design 
goal is to make display of a single package in the tree very fast by 
pre-linking important things like dependencies and provides.

The specification doubles as documentation for one of the in-memory 
structures used by the package library and the APT GUI.

</abstract>

<copyright>
Copyright &copy; Jason Gunthorpe, 1997-1998.
<p>
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.

<p>
For more details, on Debian GNU/Linux systems, see the file
/usr/share/common-licenses/GPL for the full license.
</copyright>

<toc sect>

<chapt>Introduction
<!-- Purpose		                                               {{{ -->
<!-- ===================================================================== -->
<sect>Purpose

<p>
This document describes the implementation of an architecture
dependent binary cache file. The goal of this cache file is two fold, 
firstly to speed loading and processing of the package file array and
secondly to reduce memory consumption of the package file array.

<p>
The implementation is aimed at an environment with many primary package
files, for instance someone that has a Package file for their CD-ROM, a
Package file for the latest version of the distribution on the CD-ROM and a
package file for the development version. Always present is the information
contained in the status file which might be considered a separate package
file.

<p>
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>
Also the structures and storage layout is optimized for use by the APT
GUI and may not be suitable for all purposes. However it should be possible 
to extend it with associate cache files that contain other information.

<p>
To keep memory use down the cache file only contains often used fields and
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
unused strings will also be present. The recommended implementation is to
simply rebuild the cache each time any of the data files change. It is
possible to add a new package file to the cache without any negative side
effects.

<sect1>Note on Pointer access
<p>
Every item in every structure is stored as the index to that structure.
What this means is that once the files is mmaped every data access has to
go through a fixup stage to get a real memory pointer. This is done
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 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-.

<p>
This scheme allows code like this to be written:
<example>
  void *Map = mmap(...);
  Package *PkgList = (Package *)Map;
  Header *Head = (Header *)Map;
  char *Strings = (char *)Map;
  cout << (Strings + PkgList[Head->HashTable[0]]->Name) << endl;
</example>
<p>
Notice the lack of casting or multiplication. The net result is to return
the name of the first package in the first hash bucket, without error
checks. 

<p>
The generator uses allocation pools to group similarly sized structures in
large blocks to eliminate any alignment overhead. The generator also
assures that no structures overlap and all indexes are unique. Although
at first glance it may seem like there is the potential for two structures
to exist at the same point the generator never allows this to happen.
(See the discussion of free space pools)
                                                                  <!-- }}} -->

<chapt>Structures
<!-- Header		                                               {{{ -->
<!-- ===================================================================== -->
<sect>Header
<p>
This is the first item in the file.
<example>
   struct Header
   {
      // Signature information
      unsigned long Signature;
      short MajorVersion;
      short MinorVersion;
      bool Dirty;
       
      // Size of structure values
      unsigned short HeaderSz;
      unsigned short PackageSz;
      unsigned short PackageFileSz;
      unsigned short VersionSz;
      unsigned short DependencySz;
      unsigned short ProvidesSz;
      unsigned short VerFileSz;
      
      // Structure counts
      unsigned long PackageCount;
      unsigned long VersionCount;
      unsigned long DependsCount;
      unsigned long PackageFileCount;
      
      // Offsets
      unsigned long FileList;              // PackageFile
      unsigned long StringList;            // StringItem
      unsigned long VerSysName;            // StringTable
      unsigned long Architecture;          // StringTable
      unsigned long MaxVerFileSize;
      
      // Allocation pools
      struct
      {
         unsigned long ItemSize;
	 unsigned long Start;
	 unsigned long Count;
      } Pools[7];

      // Package name lookup
      unsigned long HashTable[2*1024];        // Package
   };
</example>
<taglist>
<tag>Signature<item>
This must contain the hex value 0x98FE76DC which is designed to verify
that the system loading the image has the same byte order and byte size as
the system saving the image

<tag>MajorVersion
<tag>MinorVersion<item>
These contain the version of the cache file, currently 0.2.

<tag>Dirty<item>
Dirty is true if the cache file was opened for reading, the client expects
to have written things to it and have not fully synced it. The file should
be erased and rebuilt if it is true.

<tag>HeaderSz
<tag>PackageSz
<tag>PackageFileSz
<tag>VersionSz
<tag>DependencySz
<tag>VerFileSz
<tag>ProvidesSz<item>
*Sz contains the sizeof() that particular structure. It is used as an
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>PackageCount
<tag>VersionCount
<tag>DependsCount
<tag>PackageFileCount<item>
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 
(i.e. VerFile::Size) is stored here.

<tag>FileList<item>
This contains the index of the first PackageFile structure. The PackageFile
structures are singly linked lists that represent all package files that
have been merged into the cache.

<tag>StringList<item>
This contains a list of all the unique strings (string item type strings) in 
the cache. The parser reads this list into memory so it can match strings 
against it.

<tag>Pools<item>
The Pool structures manage the allocation pools that the generator uses.
Start indicates the first byte of the pool, Count is the number of objects
remaining in the pool and ItemSize is the structure size (alignment factor)
of the pool. An ItemSize of 0 indicates the pool is empty. There should be 
the same number of pools as there are structure types. The generator 
stores this information so future additions can make use of any unused pool 
blocks.

<tag>HashTable<item>
HashTable is a hash table that provides indexing for all of the packages.
Each package name is inserted into the hash table using the following has
function:
<example>
   unsigned long Hash(string Str)
   {
      unsigned long Hash = 0;
      for (const char *I = Str.begin(); I != Str.end(); I++)
         Hash += *I * ((Str.end() - I + 1));
      return Hash % _count(Head.HashTable);
   }
</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 singly linked
list of packages based at the hash item. The linked list contains only 
packages that match the hashing function.

</taglist>
                                                                  <!-- }}} -->
<!-- Package		                                               {{{ -->
<!-- ===================================================================== -->
<sect>Package
<p>
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.
<example>
   struct Pacakge
   {
      // Pointers
      unsigned long Name;              // Stringtable
      unsigned long VersionList;       // Version
      unsigned long CurrentVer;        // Version
      unsigned long Section;           // StringTable (StringItem)
      
      // Linked lists 
      unsigned long NextPackage;       // Package
      unsigned long RevDepends;        // Dependency
      unsigned long ProvidesList;      // Provides
       
      // Install/Remove/Purge etc
      unsigned char SelectedState;     // What
      unsigned char InstState;         // Flags
      unsigned char CurrentState;      // State

      // Unique ID for this pkg
      unsigned short ID;
      unsigned long Flags;
   };
</example>   

<taglist>
<tag>Name<item>
Name of the package.

<tag>VersionList<item>
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 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 guaranteed to be sorted
from Highest version to lowest version with no duplicate entries.

<tag>CurrentVer<item>
CurrentVer is an index to the installed version, either can be
0.

<tag>Section<item>
This indicates the deduced section. It should be "Unknown" or the section
of the last parsed item.

<tag>NextPackage<item>
Next link in this hash item. This linked list is based at Header.HashTable
and contains only packages with the same hash value.

<tag>RevDepends<item>
Reverse Depends is a linked list of all dependencies linked to this package.

<tag>ProvidesList<item>
This is a linked list of all provides for this package name.

<tag>SelectedState
<tag>InstState
<tag>CurrentState<item>
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.
<p>
CurrentState indicates if the package is installed, partially installed or
not installed.

<tag>ID<item>
ID is a value from 0 to Header->PackageCount. It is a unique value assigned
by the generator. This allows clients to create an array of size PackageCount
and use it to store state information for the package map. For instance the
status file emitter uses this to track which packages have been emitted 
already.

<tag>Flags<item>
Flags are some useful indicators of the package's state. 

</taglist>

                                                                  <!-- }}} -->
<!-- PackageFile	                                               {{{ -->
<!-- ===================================================================== -->
<sect>PackageFile
<p>
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>
   struct PackageFile
   {
      // Names
      unsigned long FileName;        // Stringtable
      unsigned long Archive;         // Stringtable
      unsigned long Component;       // Stringtable
      unsigned long Version;         // Stringtable
      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
      unsigned long NextFile;        // PackageFile
      unsigned short ID;
      unsigned long Flags;
      time_t mtime;                  // Modification time
   };
</example>   
<taglist>

<tag>FileName<item>
Refers the the physical disk file that this PacakgeFile represents.

<tag>Archive
<tag>Component
<tag>Version
<tag>Origin
<tag>Label
<tag>Architecture
<tag>NotAutomatic<item>
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.

<tag>ID<item>
See Package::ID.

<tag>Flags<item>
Provides some flags for the PackageFile, see the section on defines.

<tag>mtime<item>
Modification time for the file at time of cache generation.

</taglist>

                                                                  <!-- }}} -->
<!-- Version		                                               {{{ -->
<!-- ===================================================================== -->
<sect>Version
<p>
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
the generator. Also there may not be any duplicate entries in the list (same 
VerStr).

<example>
   struct Version
   {
      unsigned long VerStr;            // Stringtable
      unsigned long Section;           // StringTable (StringItem)
      unsigned long Arch;              // StringTable
      
      // Lists
      unsigned long FileList;          // VerFile
      unsigned long NextVer;           // Version
      unsigned long DependsList;       // Dependency
      unsigned long ParentPkg;         // Package
      unsigned long ProvidesList;      // Provides
      
      unsigned long Size;
      unsigned long InstalledSize;
      unsigned long Hash;
      unsigned short ID;
      unsigned char Priority;
   };
</example>
<taglist>

<tag>VerStr<item>
This is the complete version string.

<tag>FileList<item>
References the all the PackageFile's that this version came out of. FileList 
can be used to determine what distribution(s) the Version applies to. If 
FileList is 0 then this is a blank version. The structure should also have 
a 0 in all other fields excluding VerStr and Possibly NextVer.

<tag>Section<item>
This string indicates which section it is part of. The string should be
contained in the StringItem list.

<tag>Arch<item>
Architecture the package was compiled for.

<tag>NextVer<item>
Next step in the linked list.

<tag>DependsList<item>
This is the base of the dependency list.

<tag>ParentPkg<item>
This links the version to the owning package, allowing reverse dependencies
to determine the package.

<tag>ProvidesList<item>
Head of the linked list of Provides::NextPkgProv, forward provides.

<tag>Size
<tag>InstalledSize<item>
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 existence should have the same VerStr and Hash with different contents.

<tag>ID<item>
See Package::ID.

<tag>Priority<item>
This is the parsed priority value of the package.
</taglist>

                                                                  <!-- }}} -->
<!-- Dependency		                                               {{{ -->
<!-- ===================================================================== -->
<sect>Dependency
<p>
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, Breaks, Suggests and Recommends.

<p>
Multiple depends on the same package must be grouped together in 
the Dependency lists. Clients should assume this is always true.

<example>
    struct Dependency
    {
       unsigned long Version;         // Stringtable
       unsigned long Package;         // Package
       unsigned long NextDepends;     // Dependency
       unsigned long NextRevDepends;  // Reverse dependency linking
       unsigned long ParentVer;       // Upwards parent version link
       
       // Specific types of depends
       unsigned char Type;
       unsigned char CompareOp;
       unsigned short ID;
    };
</example>
<taglist>
<tag>Version<item>
The string form of the version that the dependency is applied against.

<tag>Package<item>
The index of the package file this depends applies to. If the package file
does not already exist when the dependency is inserted a blank one (no
version records) should be created.

<tag>NextDepends<item>
Linked list based off a Version structure of all the dependencies in that
version.

<tag>NextRevDepends<item>
Reverse dependency linking, based off a Package structure. This linked list
is a list of all packages that have a depends line for a given package.

<tag>ParentVer<item>
Parent version linking, allows the reverse dependency list to link
back to the version and package that the dependency are for.

<tag>Type<item>
Describes weather it is depends, predepends, recommends, suggests, etc.

<tag>CompareOp<item>
Describes the comparison operator specified on the depends line. If the high
bit is set then it is a logical or with the previous record.

<tag>ID<item>
See Package::ID.

</taglist>

                                                                  <!-- }}} -->
<!-- Provides		                                               {{{ -->
<!-- ===================================================================== -->
<sect>Provides
<p>
Provides handles virtual packages. When a Provides: line is encountered 
a new provides record is added associating the package with a virtual 
package name. The provides structures are linked off the package structures.
This simplifies the analysis of dependencies and other aspects A provides 
refers to a specific version of a specific package, not all versions need to 
provide that provides.

<p>
There is a linked list of provided package names started from each 
version that provides packages. This is the forwards provides mechanism.
<example>
    struct Provides
    {
       unsigned long ParentPkg;        // Package
       unsigned long Version;          // Version
       unsigned long ProvideVersion;   // Stringtable
       unsigned long NextProvides;     // Provides
       unsigned long NextPkgProv;      // Provides
    };
</example>
<taglist>
<tag>ParentPkg<item>
The index of the package that head of this linked list is in. ParentPkg->Name
is the name of the provides.

<tag>Version<item>
The index of the version this provide line applies to.

<tag>ProvideVersion<item>
Each provides can specify a version in the provides line. This version allows
dependencies to depend on specific versions of a Provides, as well as allowing
Provides to override existing packages. This is experimental.

<tag>NextProvides<item>
Next link in the singly linked list of provides (based off package)

<tag>NextPkgProv<item>
Next link in the singly linked list of provides for 'Version'.

</taglist>

                                                                  <!-- }}} -->
<!-- VerFile		                                               {{{ -->
<!-- ===================================================================== -->
<sect>VerFile
<p>
VerFile associates a version with a PackageFile, this allows a full 
description of all Versions in all files (and hence all sources) under
consideration.

<example>
    struct pkgCache::VerFile
    {
       unsigned long File;           // PackageFile
       unsigned long NextFile;       // PkgVerFile
       unsigned long Offset;
       unsigned short Size;
    }
</example>
<taglist>
<tag>File<item>
The index of the package file that this version was found in.

<tag>NextFile<item>
The next step in the linked list.

<tag>Offset
<tag>Size<item>
These describe the exact position in the package file for the section from 
this version.
</taglist>

                                                                  <!-- }}} -->
<!-- StringItem		                                               {{{ -->
<!-- ===================================================================== -->
<sect>StringItem
<p>
StringItem is used for generating single instances of strings. Some things
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
   {
      unsigned long String;        // Stringtable
      unsigned long NextItem;      // StringItem
   };
</example>
<taglist>
<tag>String<item>
The string this refers to.

<tag>NextItem<item>
Next link in the chain.
</taglist>
                                                                  <!-- }}} -->
<!-- StringTable	                                               {{{ -->
<!-- ===================================================================== -->
<sect>StringTable
<p>
All strings are simply inlined any place in the file that is natural for the
writer. The client should make no assumptions about the positioning of
strings. All stringtable values point to a byte offset from the start of the
file that a null terminated string will begin.
                                                                  <!-- }}} -->
<!-- Defines		                                               {{{ -->
<!-- ===================================================================== -->
<sect>Defines
<p>
Several structures use variables to indicate things. Here is a list of all
of them.

<sect1>Definitions for Dependency::Type
<p>
<example>
#define pkgDEP_Depends 1
#define pkgDEP_PreDepends 2
#define pkgDEP_Suggests 3
#define pkgDEP_Recommends 4
#define pkgDEP_Conflicts 5
#define pkgDEP_Replaces 6
#define pkgDEP_Breaks 8
</example>
</sect1>

<sect1>Definitions for Dependency::CompareOp
<p>
<example>
#define pkgOP_OR 0x10
#define pkgOP_LESSEQ 0x1
#define pkgOP_GREATEREQ 0x2
#define pkgOP_LESS 0x3
#define pkgOP_GREATER 0x4
#define pkgOP_EQUALS 0x5
</example>
The lower 4 bits are used to indicate what operator is being specified and
the upper 4 bits are flags. pkgOP_OR indicates that the next package is
or'd with the current package.
</sect1>

<sect1>Definitions for Package::SelectedState
<p>
<example>
#define pkgSTATE_Unkown 0
#define pkgSTATE_Install 1
#define pkgSTATE_Hold 2
#define pkgSTATE_DeInstall 3
#define pkgSTATE_Purge 4
</example>
</sect1>

<sect1>Definitions for Package::InstState
<p>
<example>
#define pkgSTATE_Ok 0
#define pkgSTATE_ReInstReq 1
#define pkgSTATE_Hold 2
#define pkgSTATE_HoldReInstReq 3
</example>
</sect1>

<sect1>Definitions for Package::CurrentState
<p>
<example>
#define pkgSTATE_NotInstalled 0
#define pkgSTATE_UnPacked 1
#define pkgSTATE_HalfConfigured 2
#define pkgSTATE_UnInstalled 3
#define pkgSTATE_HalfInstalled 4
#define pkgSTATE_ConfigFiles 5
#define pkgSTATE_Installed 6
#define pkgSTATE_TriggersAwaited 7
#define pkgSTATE_TriggersPending 8
</example>
</sect1>

<sect1>Definitions for Package::Flags
<p>
<example>
#define pkgFLAG_Auto (1 << 0)
#define pkgFLAG_New (1 << 1)
#define pkgFLAG_Obsolete (1 << 2)
#define pkgFLAG_Essential (1 << 3)
#define pkgFLAG_ImmediateConf (1 << 4)
</example>
</sect1>

<sect1>Definitions for Version::Priority
<p>
Zero is used for unparsable or absent Priority fields.
<example>
#define pkgPRIO_Important 1
#define pkgPRIO_Required 2
#define pkgPRIO_Standard 3
#define pkgPRIO_Optional 4
#define pkgPRIO_Extra 5
</example>
</sect1>

<sect1>Definitions for PackageFile::Flags
<p>
<example>
#define pkgFLAG_NotSource (1 << 0)
#define pkgFLAG_NotAutomatic (1 << 1)
</example>
</sect1>

                                                                  <!-- }}} -->

<chapt>Notes on the Generator
<!-- Notes on the Generator 	                                       {{{ -->
<!-- ===================================================================== -->
<p>
The pkgCache::MergePackageFile function is currently the only generator of
the cache file. It implements a conversion from the normal textual package
file into the cache file.

<p>
The generator assumes any package declaration with a
Status: line is a 'Status of the package' type of package declaration. 
A Package with a Target-Version field should also really have a status field.
The processing of a Target-Version field can create a place-holder Version
structure that is empty to refer to the specified version (See Version
for info on what a empty Version looks like). The Target-Version syntax
allows the specification of a specific version and a target distribution. 

<p>
Different section names on different versions is supported, but I 
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>
The generator goes through a number of post processing steps after producing
a disk file. It sorts all of the version lists to be in descending order
and then generates the reverse dependency lists for all of the packages.
ID numbers and count values are also generated in the post processing step.

<p>
It is possible to extend many of the structures in the cache with extra data.
This is done by using the ID member. ID will be a unique number from 0 to
Header->??Count. For example
<example>
struct MyPkgData;
MyPkgData *Data = new MyPkgData[Header->PackageCount];
Data[Package->ID]->Item = 0;
</example>
This provides a one way reference between package structures and user data. To
get a two way reference would require a member inside the MyPkgData structure.

<p>
The generators use of free space pools tend to make the package file quite
large, and quite full of blank space. This could be fixed with sparse files.

                                                                  <!-- }}} -->

<chapt>Future Directions
<!-- Future Directions		                                       {{{ -->
<!-- ===================================================================== -->
<p>
Some good directions to take the cache file is into a cache directory that
contains many associated caches that cache other important bits of
information. (/var/cache/apt, FHS2) 

<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 achieved.

                                                                  <!-- }}} -->

</book>