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

[Dan M. <d-...@uc...>]

On Thu, 19 Oct 2000, Eric Bischoff wrote:

> > 4) Did you literally mean to use the name "doc-contents.omf"?  This makes
> > me think of the contents list which isn't really what this file is.
> 
> Well, I don't really see why the contents list should reside in a
> different database. But this is another topic and maybe it's already
> been discussed.

The idea is that each time a doc and its metadata gets installed, we want
the system to automatically update several files.  One is the contents
list - a subject-sorted tree of documents on the system.  Another is the
table of contents(TOC) for the doc.  Another is what I'm calling an
"extended contents list".  This is the contents list with the TOC merged
into it so one could potentially navigate not only through the list of
docs on your computer, but down into particular sections of a doc.  There
may be more things in the future.

Since these files generally contain information about many documents and
are XML documents where position in the documen matter, we cannot simply
concatenate each new doc to the bottom.

(Sorry if I am misunderstanding you and you already know all this.)

After chatting with Jonathan for a while, he convinced me we should use
variables which get passed to the script.

Hopefully I haven't mutilated his idea.  I think we would do it like this:

pre-install makes a file, say '<packagename>-docs.omf'.  This is created
by merging the various OMF metadata files in the package, replacing the
URI's for each doc with the actual location it will be installed.

install does two things:

First, it installs <packagename>-docs.omf
Second, it does: scrollkeeper-install -p <path> <packagename>-docs.omf

Here <path> is the path to the scrollkeeper directory in /var, or perhaps
a particular file in this directory.

The <path> can be set by the Makefile.am:
	$(localstatedir)/mydatabase

Autoconf turns $(localstatedir) into $(prefix)/var/ which RPM likes.  So
if we are doing a plain 'make install', it points to the right place.  If
we are doing an RPM 'make install', it points into $BUILDROOT/var.

I suppose we could use this as a conditional test for whether scrollkeeper
actually enters the info into its own files.  Alternately, we could
actually have scrollkeeper run, placing the generated info under
$BUILDROOT which will be deleted later.

Does this seem reasonable?
 
Dan