GConf error

Toshio Kuratomi a.badger at gmail.com
Fri May 7 21:25:30 UTC 2010

On Fri, May 07, 2010 at 01:37:20PM -0400, Colin Walters wrote:
> On Fri, May 7, 2010 at 1:17 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> >
> > Running makefile-install-schema and makefile-uninstall-schema eventually
> > calls do_sync() which was supposed to reread the schemas.  That's currently
> > calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether
> > there's some logic in there that could cause it not to suggest syncing in
> > our current setup.
> I don't understand how this could ever work - GConf IPC happens in
> terms of ORBit which is per-uid, so a bare --makefile-install-rule
> might contact the GConf engine for uid 0 and ask it to reload, but
> that's it.  It would have to jump through hoops to contact the GConf
> running as uid 500 or whatever, and I don't see those hoops being
> jumped.
> Oh but...I see, it's a Fedora patch not in the upstream GConf code to
> run killall.  My bad looking at upstream gconf git.  Sigh...
Ah I guess that's also why I thought the code had changed.  Thought that was
something we'd pushed upstream and subsequent changes had removed parts of

> > So changing policy back to doing a killall -HUP in %posttrans should work.
> > It would be nice to know what Fedora versions are affected by this and
> > whether it will someday be fixed before updating the Guidelines, though.
> So though this still leaves a window of up to 30 seconds where after
> installing an application the schema will be invalid.  Which seems
> very likely what people are hitting.
Interesting -- so to test this we'd need:

1) Update package with new schema
2) Hopefully the package is the only thing being updated, otherwise, we
could pass the timeout if no other schema-installing packages are also
installed in the transaction.
3) Immediately try to invoke the program.

The program then reads the old gconf schema and bails out or something.

However, this would seem to mean that if the user just stops the program and
restarts it after 30 seconds it should pick up the new schema.

> I think ideally we'd have the RPM system detect a schema was installed
> and do an immediate reload once post transaction, and nuke the 30
> second timeout from gconf.  That still leaves though the problem of
> the massive copy&paste scriptlets; we could remove the killall from
> --makefile-install-rule which would help.
The current scriptlets are pretty short... perhaps even too short :-(
I had to look at the draft page for the gconf update to remember what
they're doing behind the scenes.

I remember panu and ffesti were exploring ideas in the area of autodetecting
types of files that were installed and running scripts based on that but
I don't know what they've found.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100507/e423c054/attachment.bin 

More information about the devel mailing list