GNOME Bugzilla – Bug 778735
datadir and libdir is hardwired
Last modified: 2018-05-22 14:27:19 UTC
Hi expert, When I run "ssconvert --version", it will show the following: $ /scratch/gnumeric_install-test/bin/ssconvert --version ssconvert version '1.12.33' datadir := '/scratch/gnumeric_install-test/share/gnumeric/1.12.33' libdir := '/scratch/gnumeric_install-test/lib/gnumeric/1.12.33' The datadir and libdir, according to the man page, it should be configurable using the option "-L" and "-D": Gnumeric Options --libspreadsheet-version Display Gnumeric's version -L, --lib-dir=DIR Set the root library directory -D, --data-dir=DIR Adjust the root data directory However, the options just take no effect. When I look into the code (src/gutils.c), function "gutils_init()": for non-win32 OS, the datadir just hardwired to the dir that we specified in build time: gnumeric_data_dir = g_strdup (GNUMERIC_DATADIR); the libdir, depends on something, which I don't quite understand, but finally it will wired to GNUMERIC_LIBDIR if the condition doesn't match. May I know if it is a bug? Or intended for some reason? I am going to fix it (in my own build at least), just want to know if it is a known issue or there is some reason behind ... Or I just missed something? Thanks, Hing
The man page is outdated. I don't think that has been controllable for more than a decade. Running "ssconvert --help" will give you a more uptodate list of options. The real question here is what you are trying to achieve here.
Thanks for the reply. My use case is, I need to compile my own gnumeric package in order to use "ssconvert". I just try to install all the run-time library (e.g. gnumeric, glib, atk, cairo, gtk+ ... etc) under the path /scratch/gnumeric_install-test/, after that I can redistribute my package to my QA Host and Production Host (by doing simply "copy & paste"). In QA host, we managed to put 3rd party library to /proj/copyleft/, while in production, we managed to put 3rd party library to /prod/copyleft/. The problem here is, the "ssconvert" just cannot be run in QA and Prod (even I tried to use LD_LIBRARY_PATH to reset all the run-time library path) as the "datadir" and "libdir" are hardwired to "/scratch/gnumeric_install-test/", which doesn't exist in both QA/Prod environment, and I am not allowed to create anything there due to permission issue. I understand it is our folder management issue, or we can just ask Admin to create a soft link in "/scratch/gnumeric_install-test/" so to resolve it, or the worst case is, we can have two builds, one with the install path set to /proj/copyleft, and another one with the path set to /prod/copyleft. I am just thinking the option is useful for package redistrubution. Just simple "copy & paste" we can redistribute the package to any environment, any host, the "datadir" and "libdir" can be just a reference path (i.e. ../share, rather than a full path). If it is not considered as a bug or this option is not going to be supported anymore, please let me know, I will consider to have a fix in my own repo instead. Thanks, Hing
Sorry, I mean we can redistribute the installed package to any folder if this option is available, without doing anything which relies on the path in the installing time.
Bug 534134 is related, although that is mostly(?) for Windows which we no longer attempt to support. Would an implementation of... https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html ...serve your purposes?
Thanks for pointing this. The information provided in Bug 534134 is really helpful. I can see gnumeric is somehow using the g_get_xxx_dir (xdg implementation in glib (!?) ) function to read path to serve some purpose. I assume you mean we can try to move the datadir and libdir to the XDG directory structure? XDG can be a solution. However, I am just thinking, if we are going to have code change to manage these datadir and libdir in XDG way, why not bringing -L and -D back to work again (or at least to Unix-like system)? It is because the patch in Bug 534134 look quite simple. Or if "-L" and "-D" is going to be obsolete, can we fix the datadir and libdir to be relative to the binary running path rather than an absolute path? Just my suggestion. I will try to provide my patch here (using similar way as in Bug 534134). Also I am curious in an open-source project, in this case that I reported, what to determine if this should be included in the next release? It is because it is neither a bug nor a demanding feature in my use-case. Asking this because if it is not going to be included in the next release, we would stop waiting and ask our release manager to handle the releasing issue and maintain our own version instead. Thanks, Hing
Getting this right is going to be difficult. Chances are that you are better off making a local solution for your situation, at least for now. The thing is that we are stuck with at least some of these configure flags: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/gnumeric] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] Only a few of these are directly relevant to the situation here, but it is almost certain that some users are depending on them. We cannot make changes that break things without a very good reason. A lot of thought will have to go into this. With respect to -L and -D, the situation is simpler. I don't see it would ever make sense to use different directories between different runs of ssconvert, so command line options are the wrong way to control the directories. I'll remove them from the manpage.
-- 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/gnumeric/issues/311.