6:56 a.m.
Dear all,
Has there been any discussion about this?
I thinking along the lines of htdig/swish-e that indexes all man
pages/howto/README after every rpm is installed.
Something like a post entry in the spec file, or similar.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1467 624141
M +44 (0) 7930 323266
F +44 (0) 1224 742001
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
8:21 a.m.
On Fri, 28 Jan 2005 12:56:58 -0000 (GMT), "Gavin Henry"
<ghenry(a)suretecsystems.com> said:
Dear all,
Has there been any discussion about this?
I thinking along the lines of htdig/swish-e that indexes all man
pages/howto/README after every rpm is installed.
Something like a post entry in the spec file, or similar.
I haven't seen any on this list, but essentially this is a function of
having a desktop search/indexing engine since there isn't a common
format to this stuff. The next release of yelp (GNOME help browser)
will display info and man pages, but can't index the random txt, html,
pdf etc. that goes into /usr/share/doc/.
As a non-technical workaround I wrote a Docbook section for the
Installation Guide explaining how to find the various sets of
documentation in Fedora, which is currently in my offcuts folder. It's
a bad situation for new users at the moment...
--
Stuart Ellis
s.ellis(a)fastmail.co.uk
8:39 a.m.
<quote who="Stuart Ellis">
On Fri, 28 Jan 2005 12:56:58 -0000 (GMT), "Gavin Henry"
<ghenry(a)suretecsystems.com> said:
> Dear all,
>
> Has there been any discussion about this?
>
> I thinking along the lines of htdig/swish-e that indexes all man
> pages/howto/README after every rpm is installed.
>
> Something like a post entry in the spec file, or similar.
I haven't seen any on this list, but essentially this is a function of
having a desktop search/indexing engine since there isn't a common
format to this stuff. The next release of yelp (GNOME help browser)
will display info and man pages, but can't index the random txt, html,
pdf etc. that goes into /usr/share/doc/.
We heavily use Swish-e (www.swish-e.org) for the fileservers we install.
This can handle html, xhtml, txt, pdf and the like.
Maybe something like this or a updatedocdb crontab, like slocate has and
we just put the standard doc pathnames in a config file. The customize the
web search page.
As a non-technical workaround I wrote a Docbook section for the
Installation Guide explaining how to find the various sets of
documentation in Fedora, which is currently in my offcuts folder. It's
a bad situation for new users at the moment...
--
Stuart Ellis
s.ellis(a)fastmail.co.uk
--
fedora-docs-list mailing list
fedora-docs-list(a)redhat.com
To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-docs-list
9:24 a.m.
On Fri, 28 Jan 2005 14:39:32 -0000 (GMT), "Gavin Henry"
<ghenry(a)suretecsystems.com> said:
<quote who="Stuart Ellis">
>
> On Fri, 28 Jan 2005 12:56:58 -0000 (GMT), "Gavin Henry"
> <ghenry(a)suretecsystems.com> said:
>> Dear all,
>>
>> Has there been any discussion about this?
>>
>> I thinking along the lines of htdig/swish-e that indexes all man
>> pages/howto/README after every rpm is installed.
>>
>> Something like a post entry in the spec file, or similar.
>
> I haven't seen any on this list, but essentially this is a function of
> having a desktop search/indexing engine since there isn't a common
> format to this stuff. The next release of yelp (GNOME help browser)
> will display info and man pages, but can't index the random txt, html,
> pdf etc. that goes into /usr/share/doc/.
We heavily use Swish-e (www.swish-e.org) for the fileservers we install.
This can handle html, xhtml, txt, pdf and the like.
I've just looked at the page now, but it looks like a very useful bit of
software.
Maybe something like this or a updatedocdb crontab, like slocate has
and
we just put the standard doc pathnames in a config file. The customize
the
web search page.
My understanding is that this is where things become quite technical and
problematic. There is always a disjunct between what's actually on the
disk and what is listed in the index. On portable computers it's harder
to guarantee that batch indexing jobs will be completed regularly as
well. Beagle and Spotlight use kernel hooks to update the index as
changes occur. I suppose that RPM packages could run post-install
scripts that update a document registry (kind of like you suggested)
would be a relatively non-invasive way to implement something.
I definitely think that the default start page of the Web browser could
be used very effectively by the docs project. The details of
implementing an index might be a good question for fedora-devel.
--
Stuart Ellis
s.ellis(a)fastmail.co.uk
9:46 a.m.
On Fri, 2005-01-28 at 14:21 +0000, Stuart Ellis wrote:
On Fri, 28 Jan 2005 12:56:58 -0000 (GMT), "Gavin Henry"
<ghenry(a)suretecsystems.com> said:
> Dear all,
>
> Has there been any discussion about this?
>
> I thinking along the lines of htdig/swish-e that indexes all man
> pages/howto/README after every rpm is installed.
>
> Something like a post entry in the spec file, or similar.
I haven't seen any on this list, but essentially this is a function of
having a desktop search/indexing engine since there isn't a common
format to this stuff. The next release of yelp (GNOME help browser)
will display info and man pages, but can't index the random txt, html,
pdf etc. that goes into /usr/share/doc/.
One reason I like yelp is because it can (aiui) render straight XML, so
we could put the entire fedora-docs tree on an install. I've discussed
with others the idea of having docs be more modular so they can be
linked via metadata to yelp topics. This all supposes support by the
underlying yelp code.
I like the idea of separately indexing documentation, both as a cron job
and as part of the package install process.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
IT executives rate Red Hat #1 for value
http://www.redhat.com/promo/vendor/
7027
days inactive
7027
days old
4 comments
3 participants
participants (3)
-
Gavin Henry -
Karsten Wade -
Stuart Ellis