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

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

On Mon, 13 Nov 2000, Eric Bischoff wrote:

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

Those 5 seconds are unacceptable to me. And they won't be done only the 
*first* time, they will be done everytime you install a new doc.
 
> > > 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.

I do not think that changing one line in several thousand spec files is a 
big issue. Its not like they are done by "one person". 

I agree that it would be nice to avoid thise post-install script. But the 
alternatives that have been suggested are not feasibly (in my opinion)
 
> >  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.

It doesn't "forget" - it just doesn't mention the fact that your help 
file is installed because the OMF file is not installed. Somebody will 
then complain "this app doesn't have a help file". The author would then 
properly install the OMF file.

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

I'd like to know "other" people's opinion on the post-install script 
thing (so far its mainly been a "GNOME-affiliated camp" vs. 
"KDE-affiliated camp" debate). What about the various other people's 
opinions? ;)
 
> > > 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/
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> http://lists.sourceforge.net/mailman/listinfo/scrollkeeper-devel
>