docs/package-set.xml
author J. Ali Harlow <ali@juiblex.co.uk>
Thu Feb 09 20:45:27 2012 +0000 (2012-02-09)
changeset 418 33b825d3128d
parent 311 cd292c2de0b6
permissions -rw-r--r--
Add transaction barriers
These allow packages to be installed and removed which have scripts
that depend on each other when atomic transactions are involved.
Note that yum supports pre, but not other requires flags. post will
need similar support to the post scripts themselves pulling in the
requires flags from the rpms. Likewise preun and postun will need
similar handling to those scrips since the requires flags will need
to be stored in the razor database.
krh@311
     1
<?xml version="1.0" encoding="utf-8"?>
krh@311
     2
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
krh@311
     3
krh@311
     4
<chapter id="file-format">
krh@311
     5
  <title>Package Set File Format</title>
krh@311
     6
  
krh@311
     7
  <sect2 id="file-header">
krh@311
     8
    <title>File header</title>
krh@311
     9
    
krh@311
    10
    <para>
krh@312
    11
      The rzdb file starts with a header, containing some number of
krh@311
    12
      sections, terminated by a section with type 0:
krh@311
    13
    </para>
krh@311
    14
krh@311
    15
    <programlisting><![CDATA[
krh@311
    16
struct razor_set_header {
krh@311
    17
	uint32_t magic;
krh@311
    18
	uint32_t version;
krh@311
    19
	struct razor_set_section sections[0];
krh@311
    20
};
krh@311
    21
krh@311
    22
struct razor_set_section {
krh@311
    23
	uint32_t type;
krh@311
    24
	uint32_t offset;
krh@311
    25
	uint32_t size;
krh@311
    26
};
krh@311
    27
]]></programlisting>
krh@311
    28
krh@311
    29
    <para>
krh@312
    30
      razor_set_open() mmaps the rzdb file, and creates a struct razor_set:
krh@311
    31
    </para>
krh@311
    32
krh@311
    33
    <programlisting><![CDATA[
krh@311
    34
struct razor_set {
krh@311
    35
	struct array string_pool;
krh@311
    36
 	struct array packages;
krh@311
    37
 	struct array properties;
krh@311
    38
 	struct array files;
krh@311
    39
	struct array package_pool;
krh@311
    40
 	struct array property_pool;
krh@311
    41
 	struct array file_pool;
krh@311
    42
	struct razor_set_header *header;
krh@311
    43
};
krh@311
    44
]]></programlisting>
krh@311
    45
krh@311
    46
    <para>
krh@311
    47
      by finding the sections with those IDs and creating struct
krh@311
    48
      array's pointing to the right places in the mmapped data. (This
krh@311
    49
      is the only processing needed when reading in the file;
krh@311
    50
      everything else is used exactly as-is.)
krh@311
    51
    </para>
krh@311
    52
krh@311
    53
  </sect2>
krh@311
    54
krh@311
    55
  <sect2 id="sections">
krh@311
    56
    <title>The sections</title>
krh@311
    57
krh@311
    58
    <itemizedlist>
krh@311
    59
      <listitem>
krh@311
    60
        <para>
krh@311
    61
          <emphasis>RAZOR_STRING_POOL</emphasis> Stores one copy of
krh@312
    62
	  each string that appears in the rzdb file. (At the moment,
krh@312
    63
	  this is: package names, package versions, property names,
krh@311
    64
	  property versions, and (basenames of) filenames.) The
krh@311
    65
	  strings are arbitrarily-sized, 0-terminated, and not in any
krh@311
    66
	  particular order (although the empty string always ends up
krh@311
    67
	  being at offset 0).
krh@311
    68
	</para>
krh@311
    69
      </listitem>
krh@311
    70
krh@311
    71
      <listitem>
krh@311
    72
        <para>
krh@311
    73
          <emphasis>RAZOR_PACKAGES</emphasis> Array of struct
krh@311
    74
	  razor_package; one for each package in the set, sorted by
krh@311
    75
	  name.
krh@311
    76
	</para>
krh@311
    77
      </listitem>
krh@311
    78
krh@311
    79
      <listitem>
krh@311
    80
        <para>
krh@311
    81
          <emphasis>RAZOR_PROPERTIES</emphasis> Array of struct
krh@311
    82
	  razor_property; one for each unique property in the set,
krh@311
    83
	  sorted by type, then name, then relation type (eg, "&lt;" or
krh@311
    84
	  "&gt;="), then version. (Properties with no version have
krh@311
    85
	  relation type RAZOR_VERSION_EQUAL, and version "".)
krh@311
    86
	</para>
krh@311
    87
      </listitem>
krh@311
    88
	    
krh@311
    89
      <listitem>
krh@311
    90
        <para>
krh@311
    91
          <emphasis>RAZOR_FILES</emphasis> Array of struct
krh@311
    92
	  razor_entry; one for each file owned by any package in the
krh@311
    93
	  set. The current sort order (which is subject to change)
krh@311
    94
	  is breadth-first, sorted by basename. So eg: /, /bin,
krh@311
    95
	  /dev, /etc, /bin/false, /bin/true, /dev/null, /etc/passwd.
krh@311
    96
	</para>
krh@311
    97
      </listitem>
krh@311
    98
krh@311
    99
      <listitem>
krh@311
   100
        <para>
krh@311
   101
          <emphasis>RAZOR_PACKAGE_POOL</emphasis> Array of struct
krh@311
   102
	  list, with each list item containing the index of a struct
krh@311
   103
	  razor_package in the packages section. See the discussion
krh@311
   104
	  of lists below.
krh@311
   105
	</para>
krh@311
   106
      </listitem>
krh@311
   107
krh@311
   108
      <listitem>
krh@311
   109
        <para>
krh@311
   110
          <emphasis>RAZOR_PROPERTY_POOL</emphasis> Array of struct
krh@311
   111
	  list, with each list item containing the index of a struct
krh@311
   112
	  razor_property in the properties section. See the
krh@311
   113
	  discussion of lists below.
krh@311
   114
	</para>
krh@311
   115
      </listitem>
krh@311
   116
krh@311
   117
      <listitem>
krh@311
   118
        <para>
krh@311
   119
          <emphasis>RAZOR_FILE_POOL</emphasis> Array of struct list,
krh@311
   120
	  with each list item containing the index of a struct
krh@311
   121
	  razor_entry in the files section. See the discussion of
krh@311
   122
	  lists below.
krh@311
   123
	</para>
krh@311
   124
      </listitem>
krh@311
   125
    </itemizedlist>
krh@311
   126
  </sect2>
krh@311
   127
krh@311
   128
  <sect2 id="data-types">
krh@311
   129
    <title>Data types</title>
krh@311
   130
krh@311
   131
    <para>
krh@311
   132
      Note that the exact layout of bits involves some historical
krh@311
   133
      accidents.  (Particularly the fact that the "name" field in most
krh@311
   134
      structs loses its high bits to a flags field.)
krh@311
   135
    </para>
krh@311
   136
krh@311
   137
    <programlisting><![CDATA[
krh@311
   138
struct list_head
krh@311
   139
	uint list_ptr : 24;
krh@311
   140
	uint flags    : 8;
krh@311
   141
krh@311
   142
struct list
krh@311
   143
	uint data  : 24;
krh@311
   144
	uint flags : 8;
krh@311
   145
]]></programlisting>
krh@311
   146
krh@311
   147
    <para>
krh@311
   148
      Used to store lists of package, property, or file IDs. "struct
krh@311
   149
      list_head" stores the head of the list, which points to one or
krh@311
   150
      more "struct list"s in the appropriate "pool" section.  ("struct
krh@311
   151
      list" should probably be called "struct list_item".)
krh@311
   152
    </para>
krh@311
   153
krh@311
   154
    <para>
krh@311
   155
      "list_first(&amp;head, &amp;pool)" returns a "struct list *"
krh@311
   156
      pointing to the first element of the list (or NULL for an empty
krh@311
   157
      list), and "list_next(list)" will return successive elements,
krh@311
   158
      until NULL is returned. Each "list->data" contains the index of
krh@311
   159
      a package, property, or file in the corresponding section of the
krh@311
   160
      set.
krh@311
   161
    </para>
krh@311
   162
krh@311
   163
    <para>
krh@311
   164
      Peeking underneath the abstraction, a list_head's "flags" is
krh@311
   165
      0xff if the list is empty, 0x80 if it contains a single element,
krh@311
   166
      or 0x00 if it contains more than one element. In the
krh@311
   167
      single-element case, that element is actually stored in the
krh@311
   168
      list_head directly rather than being stored in a pool (and so
krh@311
   169
      list_first() just casts the list_head* to a list* and returns
krh@311
   170
      it). For multi-element lists, list_ptr is the index in the pool
krh@311
   171
      of the first element of this list; the list continues through
krh@311
   172
      successive elements of the pool until one with non-zero flags is
krh@311
   173
      reached, indicating the end of the list.
krh@311
   174
    </para>
krh@311
   175
krh@311
   176
    <programlisting><![CDATA[
krh@311
   177
struct razor_package
krh@311
   178
	uint name    : 24;
krh@311
   179
	uint flags   : 8;
krh@311
   180
	uint version : 32;
krh@311
   181
	struct list_head properties;
krh@311
   182
	struct list_head files;
krh@311
   183
]]></programlisting>
krh@311
   184
krh@311
   185
    <para>
krh@311
   186
      name and version are indexes into string_pool. properties is a
krh@311
   187
      list of all of the package's properties, and files is a list of
krh@311
   188
      its files. flags is currently only used during razor_set
krh@311
   189
      merging, to keep track of which set a package came from.
krh@311
   190
    </para>
krh@311
   191
krh@311
   192
    <programlisting><![CDATA[
krh@311
   193
struct razor_property
krh@311
   194
	uint name     : 24;
krh@311
   195
	uint flags    : 6;
krh@311
   196
	uint type     : 2;
krh@311
   197
	uint relation : 32;
krh@311
   198
	uint version  : 32;
krh@311
   199
	struct list_head packages;
krh@311
   200
]]></programlisting>
krh@311
   201
krh@311
   202
    <para>
krh@311
   203
      name and version are indexes into string_pool. type is an enum
krh@311
   204
      razor_property_type (eg, RAZOR_PROPERTY_REQUIRES), and relation
krh@311
   205
      is an enum razor_version_relation (eg,
krh@311
   206
      RAZOR_VERSION_GREATER_OR_EQUAL). packages is a list of the
krh@311
   207
      packages that have this property. flags is currently unused.
krh@311
   208
    </para>
krh@311
   209
krh@311
   210
    <programlisting><![CDATA[
krh@311
   211
struct razor_entry
krh@311
   212
	uint name  : 24;
krh@311
   213
	uint flags : 8;
krh@311
   214
	uint start : 32;
krh@311
   215
	struct list_head packages;
krh@311
   216
]]></programlisting>
krh@311
   217
krh@311
   218
    <para>
krh@311
   219
      name is an index into string_pool, giving the basename of the
krh@311
   220
      file. start is either 0, or an index pointing to another
krh@311
   221
      razor_entry that is the first child of this entry (for a
krh@311
   222
      non-empty directory). (Entry 0 is always the root of the tree,
krh@311
   223
      so no entry could have entry 0 as a child.) flags is 0x80
krh@311
   224
      (RAZOR_ENTRY_LAST) if an entry is the last entry in its
krh@311
   225
      directory. Otherwise it is 0.
krh@311
   226
    </para>
krh@311
   227
krh@311
   228
    <para>
krh@311
   229
      Note that given a pointer to a struct_razor_entry (eg, from a
krh@311
   230
      package's "files" list), there is no way to reconstruct its full
krh@311
   231
      name without walking the entire files array up to that
krh@311
   232
      point. Because of this and other problems (fix_file_map()), it
krh@311
   233
      seems like razor_entry should be modified to include a pointer
krh@311
   234
      to its parent. (Storing full paths instead of just basenames
krh@311
   235
      would also fix this problem, but that would use much more
krh@311
   236
      memory.)
krh@311
   237
    </para>
krh@311
   238
  </sect2>
krh@311
   239
</chapter>