GNOME Bugzilla – Bug 646637
might be nice to have g_get_user_lib_dir()
Last modified: 2018-05-24 13:01:12 UTC
It might be nice to have standard way to get a location to install per user libraries, loadable modules, and plugins. Currently, it seems that every app is doing their own thing and often installing them into the home directory. Perhaps something like g_get_user_lib_dir(). It might also be nice to add this to the XDG Basedir spec so that this directory could be relocated or be conditionally set. Wonder if it needs to account for architecture too.
Created attachment 185052 [details] [review] Add a way to get per user lib dir
Created attachment 185055 [details] [review] Add a way to get per user lib dir
hi Jon This discussion occurred somewhere else recently when someone suggested it (either on the list or another bug, I think). There are a few problems with it. One of the problems is that it is generally regarded as unwise to mmap things from the user's home directory. I don't remember exactly why -- Lennart could tell you a lot more about that. Another is that, in the case of a shared home directory between multiple architectures (think NFS) you have quite some trouble. This one can be solved by having subdirectories of ~/.local/lib/ named by GNU triplets or Debian arch names or similar. I admit the idea would theoretically be nice though.
Well: * people are already installing modules and plugins in the home dir (without regard for architecture even) * Using a logical value would allow us to change to location to outside the home at some point if we wish. Currently we have modules and plugins all over the home dir in different places. ~/.gtk-3.0, ~/.gstreamer-0.10, ~/.mozilla/{plugins,extensions} etc. :(
Review of attachment 185055 [details] [review]: ::: glib/gutils.c @@ +2184,3 @@ + * On UNIX platforms this is determined using the mechanisms described in + * the <ulink url="http://www.freedesktop.org/Standards/basedir-spec"> + * XDG Base Directory Specification</ulink>. It would be good to document the behaviour of this functions on win32 @@ +2190,3 @@ + * Since: 2.30 + **/ +G_CONST_RETURN gchar* Do not use G_CONST_RETURN, but const instead. See https://bugzilla.gnome.org/show_bug.cgi?id=644611
mmap() support on NFS is something that's not guaranteed to work. However, read-only mmap() is much more likely to work properly than random access mmap() is. For plugins read-only access is generally sufficient. In any case I don't think that these compat problems really should stop us from introducing such a well-known directory, since there is simply no persistent user storage outside the home directory where we could place this, and I am pretty much convinced that we should *not* define a new non-$HOME place for it, just to make broken legacy OSes happy. So yeah, I am all for this, but please include the GNU canonical host identifier in the name, to make $HOME shareable between multiple archs. (Mhmm, maybe there should be a glib function to determine the GNU canonical host identifier?)
Oh, and the gtkdocs for the new function (and the spec too) should ask that people create a dir for their project beneath the lib dir, and that this dir should include the package version, to avoid API versioning problems. e.g.: ~/.local/lib-linux-x86_64/gstreamer-0.11/ or something like that.
I've been thinking the same thing for the other xdg dirs too. Not only for the version problems. I'm starting to wonder if we should really start namespacing everything with a fully qualified id (eg. org.freedesktop.Gstreamer). And require that apps use the same id that they use for dbus and desktop files.
Introducing org.freedesktop.GStreamer and suchlike would be quite a departure from how things have been traditionally done beneath /usr/lib and /usr/share, and as I understand it ~/.local tries to mimic those directories.
Yeah the FQN is orthogonal to this anyway.
Something to think about: should this be a pair XDG_LIB_HOME + XDG_LIB_DIRS, like XDG_DATA_HOME + XDG_DATA_DIRS?
It's worth thinking about the per-architecture questions even for the non-home version of this too. On Debian (Ubuntu, at least) we are already starting to see /usr/lib/x86_64-linux-gnu/ for example... Their primary use case there is cross-compiling (doesn't impact plugins) but it's quite easy to see it can help in the qemu CPU transparency case as well, which does impact plugins. The whole lib-vs-share thing is becoming increasingly weird....
Matthias has registered some rather strong objections to this proposal both on IRC and in email. I record those here (summarising): * we have too many special dirs already, and adding new ones doesn't help * putting executable code in ~ is dangerous from a security standpoint I don't disagree with his objections. Overall, I'm sort of ambivalent about this proposal.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/401.