Default paths in Base Directory Specification
Julio M. Merino Vidal
jmmv84 at gmail.com
Wed Sep 15 01:01:55 EEST 2004
On Tue, 14 Sep 2004 10:15:49 +0100, Mike Hearn
<m.hearn at signal.qinetiq.com> wrote:
> Julio M. Merino Vidal wrote:
> > IMVHO, that behavior is broken. The programs should work after
> > installation without
> > having to mess with the environment. In fact, they _can know_ where
> > they got installed,
> > so it's not a problem for them to access their own files.
> The basedir spec isn't about programs not being able to access their
> *own* files, it's about being able to locate *shared* files like the
> MIME database. That means you have to set it once, and then all the
> applications can use that. It's not different to setting PATH at bootup.
Ok, that makes things a bit clearer to me.
> It's done this way because the files this variable is supposed to point
> to aren't app specific, so it would be wrong to make it vary between
> applications. They are global shared desktop data which means you only
> need to set it once if you install your freedesktop stuff (mime db, menu
> definitions etc) to somewhere other than /usr or /usr/local. There's
> nothing GNOME specific about this.
Indeed, GNOME was only the most visible example.
Well, so as there should be just a single fdo installation on most systems...
this makes a bit "clearer" why the default values should not include the
However, here it goes another idea. Why don't the configure scripts take
an argument, say --with-xdg-data-dir, that specifies the path to the fdo stuff
at _build_ time? That value could be used as the default value for
XDG_DATA_DIR (similary for the XDG_CONFIG_DIR stuff), and fallback to the
current "default" if not given. This is very easy to implement (given a .m4
file with the right macros for consistency), and solves the problem.
Then, the user who is building stuff, just needs to call all configure scripts
with that argument (a thing that can be easily done from the packaging system)
and the burden of setting up the environment by the user has gone awya.
Furthermore, the problem of different installation prefixes resulting in
different values no longer exists (I mean, the problem caused by adding datadir
to the default paths). Doesn't this sound better? No need for environment
variables in almost all installations.
Julio M. Merino Vidal <jmmv84 at gmail.com>
The NetBSD Project - http://www.NetBSD.org/
More information about the xdg