On Fri, 2003-10-03 at 19:35, Aaron Isotton wrote: > Hi, > > [This was CC'd to Christian Marillat <marillat@debian.org> but I typed > 'debain' instead of 'debian' into the to field.] > > As far as I understand the Gnome help system is supposed to work like > this: > > - packages ship the documentation only in XML format > - as conversion to HTML/whatever is slow, the XML gets converted to the > appropriate formats on package installation. > - yelp displays the pregenerated HTML, and only generates it 'on the > fly' when it is not available/outdated. > > The problem is that yelp stores the generated HTML in the same directory > as the XML data is, i.e. in /usr/doc. This is of course the wrong place > for generated data, which should go into /var/cache. > > Because of that the HTML pregeneration is disabled in Debian, and this > causes yelp to be close to unusable (I experienced waiting times of up > to 1 minute), since the HTML needs to be generated *every time*. > > Christian Marillat (the Debian yelp maintainer) has tagged the bug > #177167 as 'wontfix' and forwarded it to [0]; as far as I can see, > neither him nor the Gnome developers seem to be very keen to fix the > bug. > > [0] http://bugzilla.gnome.org/show_bug.cgi?id=103777 > > As I am very annoyed by the bug, I am looking into fixing it. But I > need some information about the whole gnome help generation process. > > - what kind of documents are currenty generated from the XML sources? > HTML? PDF? PS? Others? Are they/should they all be cached? > > - what kind of structure should /var/cache/yelp have? > > - how should the cache be updated? by root running yelp-pregenerate, or > by yelp 'on first request'? If yelp must be able to write to the cache, > how should it do so? Via setuid or via group permissions (like the man > cache). > > - has any of this already been done? Is somebody working on it? The upcoming release of Yelp features a brand-new collection of XSLT style sheets that are much faster than Norm's. Because of this, the yelp-pregenerate program will be taken out of the build (unless someone is willing to work more on it, that is), and the caching you mentioned is probably unnecessary.
Attachment:
signature.asc
Description: This is a digitally signed message part