Re: what is the correct directory for scrollkeeper_localstate_dir?

[Malcolm Tredinnick <malcolm commsecure com au>]

On Mon, 2003-10-06 at 21:22, Chee Bin HOH wrote:
> After installing GNOME 2.4, I found an issue with scrollkeeper (0.3.12)
> 
> In my machine, `scrollkeeper-config --pkglocalstatedir` will actually
> give `/opt/gnome-2.4/var/lib/scrollkeeper` where $prefix is
> `/opt/gnome-2.4` while I install scrollkeeper package amd all other
> GNOME packages.
> 
> However almost all GNOME packages have a omf.make which set
> scrollkeeper_localstate_dir to `$(localstatedir)/scrollkeeper`, which is
> refer to `/opt/gnome-2.4/var/scrollkeeper`.
> 
> `make install` will update the catalog directory of
> `/opt/gnome-2.4/var/scrollkeeper` instead of the correct one
> `/opt/gnome-2.4/var/lib/scrollkeeper` given by scrollkeeper-config.

This is a long-standing (apparently) bug that has only recently been
reported. I had never seen it, since I am constantly re-installing
scrollkeeper. Somebody finally got around to reporting it about a month
ago, although they claimed they had known about it for 18 months! In
retrosepct, a couple of other problems I had seen are symptomatic of the
same problem. There is some (good) chance that we can get it "fixed" in
some sense for GNOME 2.6, but given all the old documents out there, it
is going to be a little crazy for a while.

I shall lay out all the gory details here so that we have something to
point people at in the mailing list archives. Bear with me.

The technical problem is this: on Linux systems, the per-application
directory should be ${localstatedir}/lib/<app>. On Solaris and *BSD
systems, it is ${localstatedir}/<app>. We cannot reasonably change
either of these defaults and the scrollkeeper configuration scripts
(including scrollkeeper-config) takes the differences into account (in
particular, it now gets *BSD systems correct, thanks to some help from
the 

However, the Makefile fragment we use to build the documentation only
installs things into the Solaris/*BSD default. It does not check the
results of it's own scrollkeeper-config output. The fix for this
requires changing *every* *single* *package* that installs documentation
using scrollkeeper: one line needs to be added to the configure.in
script and the Makefile fragment needs to be updated. Those packages
which use gnome-common get the last bit for free; others will need to be
updated by hand.

This is probably going to be my major documentation contribution for
GNOME 2.6: fixing this bug across the board.

> This results in no table of contents under `GNOME - Desktop` when I run
> `yelp`.

One solution is to run 'scrollkeeper-rebuilddb', which will update the
database under ${localstatedir}/lib/scrollkeeper on Linux systems.

Another solution is to link ${localstatedir}/scrollkeeper to
${localstatedir}/lib/scrollkeeper (the first time you do this, run the
above command first, so that the database is updated; then make the
link). For full points, you should link the "bad" location to the
correct location, rather than the other way around (i.e. link
.../scrollkeeper to ..../lib/scrollkeeper on Linux). That is the
traditional way of handling backwards-compatibility directory locations.

> Will it be good if we set `scrollkeeper_localstate_dir` of omf.make to
> `scrollkeeper-config --pkglocalstatedir`, so a correct
> scrollkeeper_db_dir is given by scrollkeeper-config itself?

You don't want to run this in the Makefile, it should correctly be run
in configure.in. But yes, that is the idea. It is, in retrospect, a
really silly bug.

> or maybe that is just a bug of omf.make, we should correct the
> scrollkeeper_localstate_dir to `$(localstatedir)/lib/scrollkeeper` ;)

Nope. See above (that would be wrong for non-Linux systems).

Cheers,
Malcolm