GNOME Bugzilla – Bug 354357
wrong location for scrollkeeper files after install
Last modified: 2020-03-03 18:34:12 UTC
in evince 0.5.5 the install target puts scrollkeeper files into $PREFIX/var/lib. it should be $PREFIX/lib (as stated in configurte --help too)
it seems that even passing --localstatedir, scrollkeeper files are installed anyway in 'scrollkeeper-config --pkglocalstatedir'... is this the correct behavior?
we are using quite standard document makefile from gnome-doc-utils. Do this error appear in other applications? Probably it's gnome-doc-utils bug.
Let me explain better, maybe i am misunderstanding the meaning of some "configure" switches. At this link: http://www.linuxfromscratch.org/blfs/view/svn/gnome/evince.html I read: "--localstatedir=/var/lib: This parameter is used so that all ScrollKeeper files are installed in, and the ScrollKeeper database is properly updated in /var/lib/scrollkeeper instead of some files being installed in $GNOME_PREFIX/var/scrollkeeper" So I understand that configuring evince with the switch --localstatedir=some_dir allows evince to install its own scrollkeeper files in some_dir. But this does not happen: after running configure, if you run a grep -r localstatedir * you'll see that the value of $localstatedir is never used. Indeed, the scrollkeper files destination is obtained only by running "scrollkeeper-config --pkglocalstatedir". What I would think is that if I pass --localstatedir to configure, then its value should override the one reported by "scrollkeeper-config --pkglocalstatedir". Am I wrong?
It's actually a gnome-doc-utils problem, it really don't respect localstatedir.
gnome-doc-utils intentionally uses `scrollkeeper-config --pkglocalstatedir` rather than a subdirectory of --localstatedir. ScrollKeeper has no way to merge information from multiple paths, so if you use some other directory, you'll never see those documents. As for the LFS documentation, it's just wrong. Passing --localstatedir has absolutely no effect on how scrollkeeper-update is called. Their documentation may be a relic from the old omf.make stuff. As far as I'm concerned, this is not a bug. Passing --localstatedir lets you specify which directory this module (in this case, evince) should use. ScrollKeeper is not evince, and it should use the directory it was configured to use.
(In reply to comment #5) > gnome-doc-utils intentionally uses `scrollkeeper-config --pkglocalstatedir` > rather than a subdirectory of --localstatedir. ScrollKeeper has no way to > merge information from multiple paths, so if you use some other directory, > you'll never see those documents. Shaun, I am reopening this bug not because of the irrelevent --localstatedir, but because the package prefix is completely ignored - regardless of whether you will be able to see the documentation that you just installed into your custom prefix or not, it is important to respect the custom prefix. Someone could be installing into a prefix where they dont have root privalages on the system, that means they cannot build and test packages that install sk files because they will constantly try to install in /var/lib instead of $PREFIX/var/lib. I've been bending my head around this line in gnome-doc-utils.make: _sklocalstatedir ?= `scrollkeeper-config --pkglocalstatedir` And I'm having a hard time to prefix it with the package prefix, also not sure if it would be a correct fix to prefix the path returned by scrollkeeper-config, thoughts ? Note: I am currently holding back from applying a docs patch to glade because it introduces this bug at `make install' time into a custom prefix, if its too difficult to fix in gnome-doc-utils.make at this time - do you have an idea of how we could easily work around it in the glade makefiles ?
This is really just a fundamental shortcoming of ScrollKeeper. Users who are installing somewhere local (say, ~/gnome/) can install ScrollKeeper there as well. To get ScrollKeeper to list the system-installed documentation as well, they can seed the local ScrollKeeper database with the system-installed OMF files (probably in /usr/share/omf/). It's a painful manual process, but it's feasible. I'll leave this open for now in case any bright ideas come up. But short of forking ScrollKeeper and fixing some of its more annoying inadequacies (which we should probably do), I'm not sure we can do anything.
Is this also the reason for "make distcheck" failures when ran as non-root? (bug #369550)
Danillo, yes it is. Btw. I filed https://sourceforge.net/tracker2/?func=detail&aid=1746175&group_id=11543&atid=111543 against scrollkeeper a long ago, but apparently its totally unmaintained (see the random crap in the bugtracker).
Which is exactly why we recommend adding this to your top-level Makefile.am: DISTCHECK_CONFIGURE_FLAGS = --disable-scrollkeeper
Shaun, gtk-doc already uses DISTCHECK_CONFIGURE_FLAGS = --disable-scrollkeeper Besides that I found out about this due to sheer luck (I can't see any place where this is recommended), it does not help with e.g. bug #573555 where people to --prefix=$HOME/test. Is this so hard to fix in scrollkeeper?
ScrollKeeper is, for all intents and purposes, dead. We now have Rarian, which provides a SK compatibility layer that, I believe, does not suffer this problem. If you're doing a complete Gnome installation in $HOME/test, I'd argue that you ought to install SK there as well, if you're still using SK instead of Rarian. Otherwise, well, that's why we're killing SK.
gnome-doc-utils has been superseded by yelp-xsl, yelp-tools, and itstool. gnome-doc-utils will not see any further development, hence closing as WONTFIX. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/255