Bug 49092 - Use XDG dirs instead of $HOME
Summary: Use XDG dirs instead of $HOME
Status: RESOLVED FIXED
Alias: None
Product: Spice
Classification: Unclassified
Component: unix agent (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Spice Bug List
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-23 18:49 UTC by william.jon.mccann
Modified: 2012-08-26 11:42 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description william.jon.mccann 2012-04-23 18:49:08 UTC
Current we use ~/.spice-vdagent. It would be better to follow the XDG base directory standard. http://standards.freedesktop.org/basedir-spec/latest/index.html

There are glib convenience functions for this http://developer.gnome.org/glib/2.32/glib-Miscellaneous-Utility-Functions.html#g-get-user-data-dir etc.
Comment 1 Hans de Goede 2012-04-24 10:59:55 UTC
Hi,

I'm not so sure about using xdg dirs, for the following reasons:

1) Currently spice-vdagent does not have a glib dependency
2) ~/.spice-vdagent is only used for the log file and the xdg spec says nothing about log files
3) While using the xdg dirs when starting from scratch may make sense, right now people are used to looking for the log file under ~/.spice-vdagent, I think moving it around is counter productive.

I'm going to leave this bug open for now, awaiting feedback from other developers / further discussion, but I don't plan to fix this at this time.

Regards,

Hans
Comment 2 william.jon.mccann 2012-04-24 11:53:15 UTC
The XDG standard has no dependence on glib. I was just pointing out convenience functions. The spec does not mention log files directly of course. It talks about data directories plenty though :)

We just really don't want to be littering in the home directory.
Comment 3 Hans de Goede 2012-04-24 22:58:05 UTC
(In reply to comment #2)
> The XDG standard has no dependence on glib. I was just pointing out convenience
> functions.

I know. But implementing it without the convenience functions is a bit of work, so if we go the xdg way it is really nice to have them.

> The spec does not mention log files directly of course. It talks
> about data directories plenty though :)

Right and data files != log files, specifically the spec uses ~/.local/share as data directory,
notice the share part there, and how the hierarchy below it mirrors /usr/share. Also notice how we don't put global log-files in /usr/share but in /var/log!

> We just really don't want to be littering in the home directory.

And I really want the user to be able to easily find the log file if the needs arrive.
Comment 4 william.jon.mccann 2012-04-25 12:40:15 UTC
Thinking about it a bit more. I think probably g_get_user_cache_dir() or equivalent is the right choice. So something like:

.cache/spice-vdagent/log
Comment 5 Hans de Goede 2012-04-26 00:22:27 UTC
(In reply to comment #4)
> Thinking about it a bit more. I think probably g_get_user_cache_dir() or
> equivalent is the right choice. So something like:
> 
> .cache/spice-vdagent/log

Yes, because a .cache dir is the first place a user would look for a log file. I'm sorry but it is important that when the user needs it the log file can easily be found. Maybe a ~/.log dir would work, but that does not seem to be part of the xdg spec. Since this discussion does not seem to be going anywhere I'm going to close this bug.
Comment 6 william.jon.mccann 2012-04-26 04:40:57 UTC
Users don't look in dot files either do they?
Comment 7 william.jon.mccann 2012-04-27 11:06:51 UTC
Perhaps a better solution is to use the systemd journal or syslog.
Comment 8 Hans de Goede 2012-04-28 01:25:32 UTC
Yes I will look into switching to using syslog
Comment 9 Hans de Goede 2012-08-26 11:42:09 UTC
git master has been converted to using syslog for logging, removing the usage of the ~/.spice-vdagent dir, see: http://cgit.freedesktop.org/spice/linux/vd_agent for details.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.