Re: [Scrollkeeper-devel] scrollkeeper problematic issues

[Dan M. <mu...@al...>]

Hi Ali,

I'm sorry to hear this has given you so much grief.  I think I need to 
include some information about these problems in the INSTALL file, or 
possibly in a FAQ.

It sounds like most of your problems (1, 4, and 5) are caused by not
having adequate docbook packages.  This is not surprising, because until
recently the only place that good docbook packages could be found was in
Red Hat mirrors.  This is because nobody used to use the XML catalogs, and
so distributions didn't bother actually registering docbook in the
catalogs.  Now that we are starting to use the catalog to do processing of
DocBook/XML documents, we are in a painful period where docbook
distributors need to fix their packages. To help things out, I made we
made our own packages which you can use:

     http://scrollkeeper.sourceforge.net/docbook.shtml

If you use this package, you should not have to worry about things being 
installed in strange paths where they aren't found or the need to be 
connected to the internet to build.  (It tries to find the DTD on the 
internet, since the catalog is missing or incomplete, preventing it from 
finding the DTD on your own computer.)

For #2, I believe the package is working properly.  I don't think
localstatedir is supposed to track prefix.  For example, on a vanilla
Linux installation, prefix is /usr, localstatedir is /var, and sysconfdir
is /etc.  Things which go under localstatedir belong in /var, not
/usr/var.  Similarly, things which go under sysconfdir belong in /etc, not
/usr/etc.  So, if somebody is doing something unusual, such as parallel 
installations, they should customize not only prefix but also sysconfdir 
and localstatedir.  I think a lot of people overlook this since most 
programs don't actually use sysconfdir and localstatedir and so for many 
packages customizing prefix alone is adequate.

#3 would definitely be breakage on the part of ScrollKeeper if it behaves
as you describe it.  Would you mind double-checking that it is doing what
you describe?  What do "scrollkeeper-config --localstatedir"  and
"scrollkeeper-config --pkglocalstatedir" give you?  It is running the same
commands the same way when you install ScrollKeeper and when you update
the database when new GNOME packages are installed, so I can't see how it
could change the directory.

Dan


On Sun, 28 Apr 2002, Ali Akcaagac wrote:

> hello,
> 
> please allow me to write a couple of lines related to scrollkeeper and the
> issues i got by using it. before i go into details lemme introduce my system
> here so you get a view for what i use it.
> 
> i am running a linux system here with openjade, latex, and a full docbook
> support sgml-3.1, sgml-4.1, xml-4.1.2, dssl-1.76, xsl-1.50. i use all that
> stuff to build the gnome 2 documentations and programming reference manuals.
> the catalog files are mostly these that comes with the original packages (from
> the correct webpages. no repacks, rebuilds, forks etc.). all the catalogs are
> beeing exported correctly so they can be found correctly. so far building
> gnome 2 using these packages works perfectly.
> 
> now the part where scrollkeeper takes action is something that is really
> troublesome. please let me explain the problems i have and i hope that some of
> you people could help solving these issues. either in a new scrollkeeper
> version or right now as is.
> 
> i use scrollkeeper 0.3.8 (i know its a development version). but i detected
> these issues in earlier versions too so i doubt that they will be solved any
> soon, if i dont write a few lines to point to them.
> 
> 1) i use scrollkeeper from source, compile it and install it (after libxml and
>    libxsl got installed). the problems with it is why does it search for
>    /etc/xml -> which is the same as xml-4.1.2 which is on the otherhand
>    located in my /usr/share/sgml/sgml/xml-4.1.2 directory. ok i solved this
>    issue by linking that directory to /etc/xml. i understand that people
>    install their docbook packages into different places so finding the right
>    path could be really problematic.
> 
>    i recommend adding a --path-to-xml-docbook=<path> to the configure script
>    so i dont need to link to /etc/xml and i make sure that the rest of
>    scrollkeeper get the right docbook i point to.
> 
> 2) something that also follows from one version to another. i dont use
>    /var/lib/scrollkeeper as localstatedir. i point my stuff to the same
>    prefix as scrollkeeper gets installed (default is) /usr/local where i
>    want my scrollkeeper to be installed. now if i do this.
> 
>    ./configure && make && make install
> 
>    then during configure the localstatedir wont be set correctly for the
>    scrollkeeper datafiles and configure spits out
>    $(prefix)/var/lib/scrollkeeper as it searchpath. the variable $prefix wasnt
>    changed to /usr/local as it should default to. i need to explicitely do
> 
>    ./configure --prefix=/usr/local --localstatedir=/usr/local/var
> 
>    so configure show
> 
>    /usr/local/var/lib/scrollkeeper
> 
>    after configuration. oki so far i was able solving this issues too. but
>    usually the configure script should take care if no --localstatedir was
>    defined that it at least point to the real prefix default. which it
>    currently doesnt do.
> 
> 3) another issue also point 2) related. lets say i installed scrollkeeper into
>    /usr/local/share and its database got installed to
>    /usr/local/share/var/lib/scrollkeeper. then after i compile more gnome
>    related packages, scrollkeeper doesnt use
>    /usr/local/share/var/lib/scrollkeeper to store its stuff, it puts
>    everything into a new directory named /usr/local/share/var/scrollkeeper.
>    oki since i know this happeneing, i symlink the lib/scrollkeeper dir to
>    ../scrollkeeper i know its poor but not the fault of the way i install
>    things.
> 
> 4) again this hits point 2) now after i did the /etc/xml symlink and
>    configured scrollkeeper, make and make installed it. i am getting errors
>    thrown out about not beeing able to connect to the net. or something that
>    tells me that it cant grab some stuff from net. the first time in my life
>    that i see some stuff grabbing some other stuff from net during
>    installation.
> 
>    oki solution is to make sure networkaccess is present. but anyways there
>    shouldnt be the need to have a newtwork connection to install something.
> 
> 5) related to point 2) and 4) oki now the network access is present and make
>    install throws out error messages about 'starttag not found' oki
>    investigation into this tells me that scrollkeeper has problems with the
>    the default catalogfile of xml-4.1.2. now i ask myself why does
>    scrollkeeper have problems with parsing the default catalogfile ?
> 
>    even worser on earlier versions, why is it required to generate a new
>    catalogfile so scrollkeeper understands it and even much more worse, why
>    does scrollkeeper do this on its own and trash a correct original
>    catalogfile ? i detected that my original xml catalogfile got overwritten
>    by a new made catalogfile from a previous scrollkeeper installation. i dont
>    want to say that i got really pissed by this. not to mention that i figured
>    this one out really late.
> 
> now i dont want to sound offending or something but if i had a decission i
> wouldnt use scrollkeeper at all unfortunately a lot of gnome packages requires
> it so i depend on it. i know that i will get answers like 'use a distro' use
> final 'packages' or whatever but that are all workarounds and dont cover the
> real problems.
> 
> i would be happy to get at least an answer to this. as it currently looks to
> me. scrollkeeper needs a lot of TWEAKING because it doesnt work correctly out
> of the box.
> 
>