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

[Eric B. <eb...@cy...>]

Le Dimanche 29 Octobre 2000 23:10, Dan Mueth a écrit :
> On Fri, 27 Oct 2000, Eric Bischoff wrote:
> It is worse, because an admin is willing to wait five seconds or more for
> a package to install, but users don't want to wait 5 extra seconds when
> they open their help browser.

Yes.

Well the 5 extra seconds will be on the *first* time they open the browser. 
The next times it will be much quicker. You don't install tons of packages 
every day.

> > Another solution, if the contents list is dynamic but small, is to create
> > it in the user's home directory. It's a bit of redundant work to
> > scrollkeeper to do this for each user, but it also enables each user to
> > build a contents list that matches the best its inline searches.
>
> I am hesitant to do this, partly because it seems strange and partly
> because it will cause a performance problem. At the same time, I like the
> idea of having this as an option for the future since it would potentially
> allow each user to configure their own Contents List, which would be
> great.  I think the default behavior should not be to replicate itself
> into each user's $HOME directory, but to use the system-wide database
> unless a user explicitly wants to add or remove contents.

Yes.

>  This would be
> feature which we would not implement for a long time anyway.  If and when
> we implement it, we can probably get around the performance problem by
> copying the system-wide database to start with.  However not having a
> system-wide database means that each user gets completely hammered the
> first time they open their browser.

Yup.

> > But at install time it means postinstall scripts. It's technically
> > better, but I can't figure out how distributions will react. It was
> > painful enough to change to LSB directory tree at Caldera.
>
> I agree this is a very important issue.  We have to be confident the
> distributions will accept this.  However changing the directory tree is a
> *much* bigger concern than adding scrollkeeper.

Are you sure? If you count the changed lines in the SPEC files it would even 
be worse.

>  Plus, scrollkeeper can be
> added in little pieces.  Scrollkeeper will be adopted slowly, giving
> distributions time to get familiar with it.  If GNOME 1.4 can use it, as I
> am desperately hoping, then that means that maybe 20 packages will be
> using it in the next few months.  (GNOME 1.4 should be out in about 6
> weeks, if it can stay on schedule ;)  If KDE adopts it for their next
> release along with a few other people, we are looking at maybe 70 packages
> 5 or 6 months from now.  That isn't so much to really swamp anybody.
> Plus, I'm planning that the lines we add to the spec files are completely
> generic.  Basically just cut and paste 4 lines into the spec file and you
> are done.  If you forget, then that doc doesn't show up in the contents
> list. It doesn't really break anything, so I don't think anybody is going
> to scream about a distribution forgetting to add it to a couple spec
> files.

Hmmm if your help browser "forgets" to present you with the results of your 
query it's really bad - once you have a tool you start trusting it.

> > Again, post-install scripts *are* the technical solution, but will upset
> > the distributions. There's no need for you to prove that they are better,
> > we already know it.
>
> My talks with Jonathan and Jeff (via. Jonathan) at Red Hat have indicated
> that they did not feel this would place an undo burden on distributors.
> That is my impression as well, although you (Eric), Jonathan, and Jeff
> have much more expertise in this area than I do.

> > Yes. I think we are in the heart of the problem. Sorry to have started
> > all of this, but it was a mere fact than in a distribution a "make
> > install" is done by the packager, not by the end user.
>
> It is great to have your help.  My original plan would have had many OMF
> files in each spec file and many calls to post-install scripts, which
> would have made quite a bit of work for packagers.

Even if we stick to the post-install script solution, which I do not 
encourage, it's true we did a lot of progress on this front.

> > Let me state the problem the other way round. We won't merge the OMF nor
> > the DocBook files either. So why should we merge the extra data and not
> > these ones?
>
> Aside from all the reasons I've already stated? ;)
>
> The docs and OMF files belong to the individual packages to install and
> uninstall as necessary to remain in sync with the packages.  The
> scrollkeeper database belongs to scrollkeeper, to maintain, update,
> synchronize, modify, and use as scrollkeeper needs.  I think having
> scrollkeeper's database created, shipped, and maintained (or in this case
> *not maintained*) by the applications (in many pieces) instead of
> by scrollkeeper greatly restricts scrollkeeper's ability to do its job.

Do we have a real evaluation of the cost of having a split database?

> Well, I prefer the post-install script, which is why I do not emphasize
> this solution.  However, if we *really* wanted to avoid the script, we
> could do something like: Have a magic directory every package installs a
> file into, say /var/lib/scrollkeeper/packages.  Each package installs a
> short file in here which lists the full path to the OMF file(s) installed
> by the package.  Then whenever scrollkeeper is run it checks to see if
> there are any new, modified, or missing files in this directory.  If so,
> it updates its database.

It's what I'm suggesting for ages. The only real drawback with this solution 
is the delay when you first need the merged database. And I'm not sure it 
will be 5 seconds. Of course there are the other problems like the rights but 
we know there are solutions.

>  The advantage is that it still uses one database
> making things simpler and it can keep the versions correct.  The downside
> is that it still has the permissions and performance problem, it requires
> all packages to install something into a special directory, and it is
> generally hokey.  Plus it has to detect when a file has been modified,
> which means either comparing the contents or checking timestamps, neither
> of which seem pretty.


-- 
Éric Bischoff  -  Documentation and Localization
Caldera (Deutschland) GmbH - Linux for eBusiness
Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
http://www.caldera.de/