[Bug 70990] [1.0] Logger parallel-installability

[bugzilla-daemon at freedesktop.org]

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

--- Comment #33 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(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.)

(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.)

(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.

> 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.

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