Profile include support

[Greg Hudson]

On Mon, 2010-08-23 at 18:08 -0400, Ken Raeburn wrote:
> Russ is right, this should be fixed, whether as part of this project
> or separately.  But if krb5_init_context can fail because of a profile
> library error, it becomes difficult to pass the error back to the
> application, even with profile library API changes.  If we can go
> config-file-free (I forget, did that ever get fully implemented?),
> then certainly the krb5_context can hold the profile library error
> info.

This is a good point.  I'm now convinced that improving profile error
diagnostics has to be out of scope for profile includes.  If we aren't
allowed to take baby steps without fixing all of the Looming Underlying
Architectural Weaknesses in the process, nothing will get done.

We can operate config-file-free if the default realm is unimportant and
any relevant KDCs can be auto-discovered.  But if krb5_init_context()
returns success, then how is the application going to know to look for
profile library error info?

(In Russ's bad usability situation, krb5_init_context() decided to go
config-file-free when krb5.conf existed but was unreadable, and a
subsequent operation failed because the default realm was important.)

Russ wrote:
> Unfortunately, the main thing that I'd want is the very hardest thing
> to accomplish, namely some sort of error message stating which file
> couldn't be opened and what the error was sent to somewhere where we'd
> see it.

We do have this new trace logging facility in 1.9, which I hope will
become the first thing people try when the library behaves unexpectedly.
But putting tracing events into libprofile code has the same problem as
putting extended error messages there: no krb5 context.

On another note, I believe somebody asked about profile writing in the
presence of includes, and I think that person they didn't cc the list
(and that I deleted the message by mistake).  The current design is that
the profile object won't remember what lines came from what file, so
profile_flush() or similar operations will flatten out the contents into
the main file.  Given the other limitations of profile_flush(), I think
that's okay.