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

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

On Mon, 23 Oct 2000, laszlo kovacs wrote:

> > 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
> I dont know if this breaks Eric's principle of doing the same thing by
> make install when is run for package creation or when it is run for
> install. For Solaris we would still need post install scripts. I would
> go for either post install scripts or partial databases, but we should
> keep it simple, so I dont like the idea of using different approaches
> for different package formats. 

What exactly is the proposal? I don't understand how post-install or 
partial databases could fix the problem?

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.

> > 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).
> 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.

Regards,
Ali