Re: [Scrollkeeper-devel] What about the distributions?

[Ali A. <ALI...@au...>]

On Mon, 23 Oct 2000, laszlo kovacs wrote:

> [snip]
> 
> > The line "scrollkeeper somearguments" in the "install:" section of the
> > Makefile adds or remove information in some kind of database, right?
> > Some kind of pointer to the real help file and to the OMF file,
> > information about the category in the contents list it belongs too, or
> > some other kind of information? *THIS IS THE PART THAT MIGHT CAUSE A
> > PROBLEM*. When the packager runs "make install", then either:
> > 
> > a) Scrollkeeper assumes that the database exists previously on the hard
> > disk - then make install will simply fail, because packages are built
> > usually on /tmp with what is called "buildrooting". This means that if
> > you database is normally in /usr/share/scrollkeeper, then make install
> > works with /tmp/usr/share/scrollkeeper. (BTW, this means that
> > scrollkeeper should accept a --prefix argument or something similar).
> Scrollkeeper uses the prefix argument. It knows where it was installed
> and in the current implementation all the files created or updated by it
> (including the database) go into prefix/var/lib/scrollkeeper. So
> according to the current implementation scrollkeeper will always find
> from a  "make install"  the right database even if that is run from the
> command line or from an RPM creation process. I just realised this so
> Dan's suggestion wouldn't work (at least according to the current
> implementation).

Would it be possible to change the database using an environment 
variable? ;)

Secondly, how about .spec files set an environment variable to 
OMF_NO_INSTALL when building? (and unset it when done) - Then 
scrollkeeper can detect it and just not install the file into its 
database.

This would work for tarball users too :) 

Sure, there are corner cases where it won't work (compiling an RPM in the 
background and compiling a tarball in the foreground (with rougly 
similiar install times)). But I don't like corner cases :P

> > b) If the database does not exist previously, then it creates it. Then
> > in /tmp you will find a partial database with the information relative
> > only to the docs that are in this package. Either this partial database
> > can be simply copied under a unique name and the help browser must be
> > able to cope with a database that is split over several files, either
> > there's a "merge" option to scrollkeeper that must be copied into the
> > postinstallation section of the spec file (or install.sh on a
> > slackware), and the distribution packager has four extra lines to add to
> > his spec file and he curses you.
> Multiple database files processing in the Help Browser could be
> implemented obviously. The problem here is that Scrollkeeper is supposed
> to be the universal document cataloging system for every help browser.
> That means it is supposed to offer the simplest possible interface for
> the browser. However the reality at the moment is that the only help
> browser that will use Scrollkeeper in the near future is Nautilus and we
> develop the Nautilus module that will use Scrollkeeper so we can adapt
> the code easily. One possible solution would be that we would supply a
> library that would compile the partial database files to one XML DOM
> tree and pass that to the browser. I wonder how much overhead this would
> create at start-up if there are a couple of hundreds (or thousands) of
> partial database files.

I don't think you should pass the XML DOM tree. I think there should be 
API functions (or commands or whatever) to allow you to get every item in 
the tree. Also, to speed things up, there should be a cache (so you don't 
have to re-build the XML DOM tree all the time).

Regards,
Ali

> Laszlo
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> http://lists.sourceforge.net/mailman/listinfo/scrollkeeper-devel
>