Profile include support, round 2

[Greg Hudson]

On Tue, 2010-08-24 at 13:28 -0400, Ken Raeburn wrote:
> Under "interface design" it says "line[s] from the file are parsed as
> if they belonged to the original profile file".  Does that mean the
> included file's contents are effectively substituted in the middle of
> the including file, and parser state like the current section is
> oblivious to the multiple-file structure?

Correct.  My assumption is that operating systems will put something
like "includedir /etc/krb5.conf.d" at the end of their standard
krb5.conf files, and the fragments for modules would all begin with
[plugins].

It might be relatively easy to enforce this by effectively unsetting the
current section before and after including a file.  I'll look into this.

> Are include directives in the included files processed recursively?

Yes.

> I think I'd add "-" to the list of characters to accept in filenames
> in a directory.  I'd anticipate $dir/krb5.conf.${packageName} or just
> $dir/${packageName} to be used in some cases, and I'd expect "-" to be
> used there a lot.  Or is "foo-" used as a backup file name a lot?

I'll allow hyphens; I don't think there's a problem there.

> Ignoring the problem of relative pathnames is a bad idea.  If nothing
> else, you should document a recommendation against using relative
> paths in production environments.  (And if you think you might want to
> change the interpretation later, document that potential future
> incompatibility too.)

I'm happy to document that absolute paths should be used.  As for
whether simply allowing cwd-relative paths is a bad idea, I'm deferring
to Russ's experience.

Also, while it's easy to disallow relative paths or interpret them
relative to some particular directory on Unix, it's more challenging to
remain portable to Windows when you play those kind of games with the
path.