Re: sepgsql contrib module - Mailing list pgsql-hackers

>>> 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-regtest1.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@ak.jp.nec.com>