Apply LDAP update files in blocks of 10, as originally designed.

In order to have control over the order that updates are applied
a numbering system was created for the update files. These values
were not actually used.

The updates were sorted by DN length and in most cases this was
adequate for proper function. The exception was with roles where
in some cases a role was added as a member of a permission before
the role itself was added so the memberOf value was never created.

Now updates are computed and applied in blocks of 10.

https://fedorahosted.org/freeipa/ticket/3377

1 files changed, 19 insertions, 4 deletions

diff --git a/install/updates/README b/install/updates/README
index 064c6159f..175280454 100644
--- a/install/updates/README
+++ b/install/updates/README
@@ -2,7 +2,22 @@ The update files are sorted before being processed because there are
 cases where order matters (such as getting schema added first, creating
 parent entries, etc).
 
-10 - 20: Schema
-20 - 30: FDS Configuration, new indices
-30 - 40: Structual elements of the DIT
-40 - 50: Pre-loaded data
+Updates are applied in blocks of ten so that any entries that are dependant
+on another can be added successfully without having to rely on the length
+of the DN to get the sorting correct.
+
+The file names should use the format #-<description>.update where # conforms
+to this:
+
+10 - 19: Schema
+20 - 29: 389-ds configuration, new indices
+30 - 39: Structual elements of the DIT
+40 - 49: Pre-loaded data
+50 - 59: Cleanup existing data
+60 - 69: AD Trust
+70 - 79: Reserved
+80 - 89: Reserved
+
+These numbers aren't absolute, there may be reasons to put an update
+into one place or another, but by adhereing to the scheme it will be
+easier to find existing updates and know where to put new ones.