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

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

* Eric Bischoff (eb...@cy...) wrote at 23:12 on 25/10/00:
> Ali Abdin wrote:
> > 
> > What exactly is the proposal? I don't understand how post-install or
> > partial databases could fix the problem?
> 
> When the packager does "make install" on his build machine, then
> scrollkeeper finds no existing database because usually it is building
> in
> /tmp.

You can figure out where the Scrollkeeper databasebase is easily (just add a
'scrolkeeper-config' script so 'scrollkeeper-config --prefix'/lib/scrollkeeper
would be the database location)
 
> Scrollkeeper has three options in front of a non-existing database:
> - exit with an error code. Bade, it means that the build has failed
> - do nothing, but then we lose the database information it wanted to
> store
> - create a new database and store into it the partial information
>   (i.e. the information relative to this package's doc files)
> 
> Suppose we take the third solution. Now we have a partial database. What
> do we
> do with it?
> 
> - the SPEC file can simply copy it, with a unique name, on the user's
> hard disk. But then the browser has to cope with that, perharps with
> some help from scrollkeeper
> 
> - or scrollkeeper can merge it with the existing big single-file
> database on the user's hard disk. Technically simple and efficient, but
> has two drawbacks: it obligates the distribution packagers to modify the
> SPEC files, and it slows down the post-installation phase.
> 
> > Perhaps we can really do a normal install of the OMF file. When
> > ScrollKeeper access the metadata it would check that the file "really
> > exists" if it does then okay, if it doesn't it gets deleted from the
> > database and "not found" is returned.
> 
> The RPM system assumes that what you do during a "make install" is
> exactly the same whether the end user does it or the packager does it.
> The only difference is buildrooting (i.e. / => /tmp)
> 
> > > Maybe. I was trying to stress the importance of presenting a unified
> > > database rather than lots of partial databases to the help browser (in
> > > case Scrollkeeper output would be partial databases). The implementation
> > > is not that important at the moment.
> > 
> > I agree.
> 
> The implementation is not important, but the problem that we *might
> have* partial databases must be addressed.

Partial databases would suck. basically you are saying a "database per file"
which would suck if you have hundreds of files! (imagine Scrollkeeper has to
open each file, read from it, build XML tree, close file, extract metadata).
It would be much more efficient to do this over one file.

I think forcing people to use a post-install spec-file is not as "bad" as the
alternative.

You "could" turn scrollkeeper into a daemon that automatically merges "partial
databases" into a big one, or you "could" install a cron script. But to me
these are even worse solutions than just making people add an extra script to
the spec file.

Your arguments for no script in the spec file are:

1) It'll take more time for the RPM or DEB to install due to the "slow"
post-install/post-uninstall scripts

- oh wow, an extra couple of seconds for the RPM or deb to install/uninstall???
  I don't think this is that big of a deal

2) People are not going to want to change the spec files. 

- Well, if people want to use scrollkeeper, then they will have to write an
  OMF file, hack the Makefile.am's and possibly configure.in's - What would be
  wrong with adding the spec file to this list too? If you want your docs to
  utilize scrollkeeper, then you will have to support it.

Any other points?

Regards,
Ali