Re: [Tracker] PATCH: Allow specifying user data & cache directory paths in DConf

[Martyn Russell <martyn lanedo com>]

On 12/08/13 07:43, Jonatan Pålsson wrote:
> Hi!
>
> On 9 August 2013 16:29, Martyn Russell <martyn lanedo com> wrote:
> > On 08/08/13 14:42, Jonatan Pålsson wrote:
> > > Hi list,
> >
> >
> > Hello Jonatan,
> >
> >
> > > I would like to re-locate the user data directory and user cache.
> > > Currently these directories are retrieved using g_get_user_data_dir ()
> > > and g_get_user_cache_dir (), which in turn may be affected by the user
> > > by setting appropriate XDG_* variables. I would however like a more
> > > persistent setting, so I added the user-cache-dir and user-data-dir
> > > keys to the org.freedesktop.Tracker.DB namespace in DConf.
> > >
> > > The behavior of the two keys is similar. If the key is set, it takes
> > > precedence over g_get_user_*_dir () and the supplied path is used for
> > > storing the files. If the key is empty (the default setting), the old
> > > behavior is preserved.
> > >
> > > Please see the following patch:
> > >
> > > https://github.com/Pelagicore/tracker-ivi/commit/213456024d686305d0f6a30b09fa81f04e601fdd
> > >
> > > I also have a patch for setting the path to the ontology directory. I
> > > will submit it in a different thread to keep the discussion separate.
> >
> >
> > Can I ask why do you need this sort of patch?
> >
> > You can accomplish everything the patch achieves AFAICS by just setting the
> > $XDG_CACHE_HOME, $XDG_CONFIG_HOME and $XDG_DATA_HOME environment variables
> > before running any one of the Tracker binaries. In fact, this is what I do
> > in the script I wrote to have localised Tracker DBs for different datasets.
> >
> > I would like to avoid adding more config and maintenance burden to specify
> > locations. We already have a lot of that.
> >
> > Is there some reason the env vars are not enough?
>
> Yes, the same functionality can be accomplished by using the
> environment variables already in place. I think the configuration
> options make it clearer for the user that these values can be changed
> however. By having the options available in the config, they are

The user shouldn't be changing these sort of things though.
This is really an option for packagers and people who are integrating 
Tracker into their environment.

> easier (in my opinion) to set for users. Previously, with the
> environment variables, a wrapper script had to be written to
> accomplish the same thing.

I guess that depends how launch things.

If the environment is set in your ~/.bashrc (for example), then there is 
no wrapper script needed).

It sounds like you need a unique solution here for "a" user, not all 
users. Consider that adding an option like this and setting up the 
config per user is much more involved than using a wrapper script or the 
correct .bashrc / skeleton.

> Ideally, I would like all available options not set at compile time to

This isn't a compile-time thing. It's a run-time thing.

> be in the config. This would make the config a centralized place for
> all configuration, and users could inspect it (and also get valuable
> descriptions for each option if using a graphical configuration tool).

> Settings can be exported using "dconf dump" and loaded using "dconf
> load" - which would allow a user to save all settings and restore them
> at a later point. This only makes sense if all settings are stored in
> dconf however.

Do you have a real use case for this?
Most users, in fact, I would wager a great deal of them don't know where 
the databases are or really care. Again, I see this more as a packaging 
/ systems integrator issue than a user issue - and the config is 
primarily for user configurable options.

> We probably have different visions for the config, mine is to make it
> a central repo for *all* configuration. What is the official stance on
> what goes in the config and what goes elsewhere?

There is no official stance really.

With each configuration option you add maintenance burden. If users 
aren't interested in changing an option we generally remove it. We do 
use environment variables to override a lot of stuff, see:


https://developer.gnome.org/libtracker-sparql/unstable/tracker-overview-environment-variables.html

These are not what we would generally expect a user to be playing with 
though. They are more debugging / operational changes which systems 
architects may choose to use for whatever integration purposes they're 
considering.

> Also, Philip: I have a new set of patches which should fix the issues
> you showed. I will wait with submitting them until I know whether this
> idea is at all interesting! :)

Which issues?

> Thanks to both of you for reviewing the idea & patch!

Thanks Jonatan ;)

--
Regards,
Martyn

Founder & Director @ Lanedo GmbH.
http://www.linkedin.com/in/martynrussell