Advice for distributing schemas for OpenLDAP

[ghudson@mit.edu]

MIT krb5 has an LDAP back end for its KDC, which uses its own schema.
Currently, we distribute just a .schema file for OpenLDAP, which isn't
very friendly to a DS using back-config and slapd.d.  I have some
questions about how we might do better.

1. For initial installs, I take it we should distribute a .ldif file
which can be loaded with ldapadd.  If we continue to use our .schema
file as the master source file for the time being, then I assume we'll
want to convert that to the .ldif file using slaptest.  If we do that,
should we remove the {n} prefix from the cn of the converted output,
along with the metadata entries at the end, to match the style of the
.ldif files in servers/slapd/schema?

2. If someone is upgrading to a version of krb5 which has new stuff
added to the schema, how should we facilitate that upgrade?  I don't
think the .ldif file mentioned above would be of much use, since
ldapadd will refuse to change an existing entry and ldapmodify wants
to see change records.

One option is to distribute an LDIF file with a bunch of idempotent
modify operations to upgrade the schema.  Looking at RFC 2849, I'm not
sure you can idempotently create an LDAP entry with LDIF (so this
input file couldn't be used for initial installs), but perhaps it's a
viable option to bring the olc* attributes on an existing schema entry
up to date.  Has anyone done something like this before, and is there
a good way to generate such an ldapmodify input file from either a
.schema file or its attrval-record .ldif equivalent?

Another option is to distribute delta LDIF files for each specific
upgrade.  That seems less friendly to OS packagers, who would then
have to identify which upgrades to apply, but perhaps it's a better
approach for reasons I don't know yet.  If it is the best option,
again, is there a good way to generate such delta LDIF files
automatically?

Thanks for any advice, and apologies if I missed anything in the
documentation or mailing list archives.