[Bug 70990] [1.0] Logger parallel-installability

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Jan 14 05:02:01 PST 2014


https://bugs.freedesktop.org/show_bug.cgi?id=70990

--- Comment #37 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> ---
(In reply to comment #33)
> (In reply to comment #27)
> > > tests/logger/Makefile.am doesn't adjust XDG_DATA_HOME. Should it?
> > 
> > It was already set.
> 
> tests/logger/dbus/Makefile.am does set it, but tests/logger/Makefile.am
> doesn't? (Perhaps that doesn't matter, though.)

Yeah all the actual tests are in tests/logger/dbus.

> (In reply to comment #28)
> > > This is only OK for the tests because we have a hard dependency on GLib
> > > 2.36, in which g_get_home_dir() respects $HOME. I think this deserves a
> > > comment?
> > 
> > What do you mean? Purple logs are always stored in ~/.purple anyway.
> 
> Before GLib 2.36, g_get_home_dir() used the equivalent of `getent passwd` to
> find the home directory, and ignored $HOME. (There was a Debian-specific
> patch to use $G_HOME.)

Ah I see. Adding a comment.

> (In reply to comment #30)
> > > I can see that there's value in being able to make a sqlite store read-only,
> > > but it should be mentioned in the commit message, which currently implies
> > > that only the XML store got this treatment.
> > 
> > I just naively implemented the property in each implementation of the log
> > store interface, wich requires a setting function as the property is write
> > only.
> 
> Ah, I understand now.
> 
> I think the Pidgin log store should g_warn_if_fail (writable == FALSE) or
> something, and be read-only anyway.

Good point; adding that.

> > Actually I'm wondering if it wouldn't be easier/cleaner to turn the store
> > iface to a base class so it could implement the property itself, saving us
> > to do it in each store. What do you think?
> 
> Neutral. If you want to do this I won't stop you, but I don't fully
> understand how much of this stuff is exposed to API users, and interface >
> class in terms of minimizing API guarantees.

Fair enough; let's keep it as it for now.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the telepathy-bugs mailing list