Re: [Scrollkeeper-devel] Scrollkeeper delay

[Malcolm T. <ma...@co...>]

On Sat, 2003-06-21 at 00:52, Dan Mueth wrote:
> On 20 Jun 2003, Malcolm Tredinnick wrote:
> 
> > On Fri, 2003-06-20 at 21:09, Pablo Fernandez wrote:
> 
> > > Is there anyway to avoid the rebuild of the database without rebuilding
> > > the packages that use the scrollkeeper-update program?
> > 
> > Not easily. An ugly, but possibly workable solution would be to
> > temporarily alias the scrollkeeper-update name to something harmless
> > like ':' and then run scrollkeeper-update once as part of some
> > post-install fixup.
> 
> Is the system really doing a complete rebuild of the database?  If so, 
> then it is duplicating work and it would make sense to have a way to turn 
> scrollkeeper off (such as temporarily replacing the binary or having a 
> line in /etc/scrollkeeper.conf).  Then when the distribution installation 
> is done, you should update the database.

I was thinking about this while falling asleep last night and realised a
solution might be to have an environment variable that prevented a
database rebuild in a big install scenario. So if
SCROLLKEEPER_NO_REBUILD is set in the environment, scrollkeeper-rebuild
just exits when called without doing anything. This can the be disabled
an re-enabled at will and doesn't require hacking any files . The latter
case can lead to inconsistencies if the install failed or the machine
crashed or something, whereas an environment variable would just
harmlessly disappear.

> However, when each package installs, it should only be doing an update of 
> the database.  Since these are incremental, it shouldn't be much faster to 
> do one large update at the end of the distribution installation than to do 
> a number of smaller updates during the installation.

Hmm. This is a valid point. It will be slightly faster, but not a lot.

[...]
> The real solution to this problem is to extend ScrollKeeper so that one 
> can process the docs at build time and install the generated data so that 
> ScrollKeeper doesn't have to do it at install time.

Can you explain this a bit more, because I am stupid and do not
understand. :-(

We already run scrollkeeper-preinstall in the build phase and
scrollkeeper-update in the install phase. So it sounds like you are
proposing some kind of optimised output from the build phase so that the
update part will be faster at install time, but, like I said, I don't
really understand.

Cheers,
Malcolm