Re: sepgsql contrib module

>>> 2. The docs contains some references to /usr/local/pgsql/share.. Does
>>> this really mean "whatever sharedir you established when you ran
>>> configure", i.e. the output of pg_config --sharedir? I hope so.
>>>
>> Yes, it means the sharedir being configured.
>>
>> I found the following description at the installation.sgml.
>> I should put this kind of mention on the documentation.
>>
>> |<para>
>> | These instructions assume that your existing installation is under the
>> |<filename>/usr/local/pgsql</> directory, and that the data area is in
>> |<filename>/usr/local/pgsql/data</>. Substitute your paths
>> | appropriately.
>> |</para>
>
> Why does the user need to know about this at all? Doesn't make
> install put everything in the right place?
>
It seemed to me a convenient writing-style to inform users an installation
path of file. What I like to write is showing users what path stores what
files needed in installation process.

If we use result of the `pg_config --sharedir` here, how about this
writing style? Or, do we have any other ideas?

<screen>
$ su
# SHAREDIR=`pg_config --sharedir`
# semodule -u $SHAREDIR/contrib/sepgsql-regtest.pp
# semodule -l
:
sepgsql-regtest 1.03
:
</screen>

>>> 5. I'm not too sure about this one, but I think it might be good to
>>> elaborate on what we mean by respecting the system SE-Linux policy.
>>> What kinds of objects do we support checks on? What sorts of checks?
>>> What kind of access can we allow/deny?
>>>
>> I guess these detailed description makes amount of this chapter
>> disproportionally increase in the future version.
>> My preference is wikipage to provide this kind of detailed information.
>>
>> http://wiki.postgresql.org/wiki/SEPostgreSQL
>>
>> The contents of above wikipage is now obsoleted, because it assumed
>> SELinux support as a built-in feature. But it is a good time to fix
>> up the description.
>
> I'd prefer to have it in the actual documentation. I think
> SE-PostgreSQL is going to need a lot of documentation. A wiki page
> risks getting out of date or having the wrong information for the
> version the user has installed. 9.1 may be quite different from 9.2,
> for example.
>
Indeed, wikipage might not be suitable to document for several different
version. OK, I'll try to add description what you suggested above.

> Most of what you have here right now describes why you might
> want to use this feature, rather than what the feature actually does.
> If you want to start by updating the wiki page, that's fine, and may
> be an easier way for us to collaborate than doing it by exchanging
> patches. But ultimately I think it needs to go in the docs.
>
The background of this wikipage is that I was persuading people
this feature being worthful, so the contents tend to philosophical
things rather than actual specifications.

I also think wiki page allows us to brush up the documentation
rather than exchanging patches effectively. I'll set up a wiki page
that contains same contents with *.sgml file to revise documentation
stuff to be included into the *.sgml file finally. How about this idea?

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>