[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