Another GConf question

DJ Lucas dj at
Sat Dec 4 21:40:02 PST 2010

On 12/04/2010 06:40 PM, Randy McMurchy wrote:
> DJ Lucas wrote these words on 12/04/10 12:39 CST:
>> On 12/04/2010 10:23 AM, Randy McMurchy wrote:
>>> I meant to add this question to the previous email and forgot so here
>>> goes. If ${GNOME_PREFIX} is not /usr, the following file is created:
>>> /opt/gnome/share/sgml/gconf/gconf-1.0.dtd
>>> Though there is no catalog file associated with this dtd, does the system
>>> /etc/sgml/catalog need to be updated to reflect this file, or will GConf
>>> know to look in the alternate prefix when it needs this dtd file?
>> Randy, I don't know about this particular one as I don't rebuild
>> documentation, however, there are some issues if not installing in /usr.
> Are you certain that the gconf-1.0.dtd has anything at all to do with
> rebuilding documentation? I thought GConf was a mechanism for maintaining
> a configuration database, and the DTD was used to ensure all the entries
> in the database use consistent syntax. I just wondered if somehow GConf
> used the system-wide /etc/sgml and /usr/share/sgml stuff and because the
> installed DTD file is not mentioned in either of those places, I was curious
> if GConf was able to use it.

I honestly do not know.  I hadn't noticed it until you mentioned it, but
it is right there in my installed file logs. I've not noticed any issues
with GConf fussing about it (else it would have been pretty obvious what
the problem was I'd think).

> It probably doesn't need to relate at all with /etc/sgml or /usr/share/sgml
> because I've never had an issue with GConf complaining that it could not
> update the database when it wanted to. I was just curious.

I don't have an answer beyond that it seems to have worked fine for a
long time that way. GConf will be going away with Gnome-3.0 so it will
certainly not be a problem going beyond this release (valid, but useless
comment). :-)

-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the blfs-dev mailing list