On Tue, 14 Nov 2000, Laszlo Kovacs wrote:
> > > This would pose a significant problem. The original design installed each
> > > document with something like:
> > >
> > > scrollkeeper-install <omffile> <doc>
> >
> > I think that's probably a bad idea. Each OS is going to have its own idea
> > of what program to use to physically install the document, and set the
> > ownership and permissions properly. I don't see much point in reinventing
> > install(1) or cp(1).
>
> This is a misunderstanding. It is an addition to install and cp, not a
> reinvention. It installs the doc into the Scrollkeeper database after it
> was installed with install or cp to the right location.
>
> > I think it's probably better to provide a scrollkeeper configuration
> > file (in XML would be nice :-) ) that describes a list of paths down
> > which scrollkeeper (sk from now on) should recurse to look for new
> > documentation.
> There will be some solution in the future to extend the one directory
> where metadata files are now to a set of directories. This is for
> metadata only, Scrollkeeper intends to support cataloging of docs based
> anywhere locally and on the web, this is why we thought the metadata
> should contain the url.
Perhaps we should use a URI instead of a URL (so a local file would be
'file:///usr/doc/foo.sgml' or
'http://scrollkeeper.sourceforge.net/manual.sgml' - but that would suck,
because you'd have to handle the URI parsing (which will just duplicate
code that is in gnome-vfs (and prolly some other KDE library out there))
> > Most package systems should provide a mechanism to call scrollkeeper-install
> > after a document has been added to the system, ideally with the path in
> > which the document was installed. For those that don't, the system can
> > run something periodically that re-indexes the list of installed
> > documentation, in the same way that the apropos database is built at the
> > moment.
> The problem with this is that packagers will have to create large
> postinstall scripts to get it working right and some of the people on
> this list think they will not do it if the changes are not as simple as
> possible. If we disregard the packagers possible reaction then most/all
> of the Scrollkeeper related process should be launched from postinstall
> scripts. But as I said some people strongly opposed that.
>
> > Depends how well written the package is. Most of the FreeBSD ports install
> > with $PREFIX set to something other than /usr/local with no problems.
> >
> > Also, keep in mind that some of these packages are going to consist of
> > nothing but documentation.
> >
> > For example, *right now*, a FreeBSD user can do something like
> >
> > pkg_add -r -p /opt/share/doc \
> > ftp://ftp.freebsd.org/pub/FreeBSD/doc/packages/handbook.en_US.ISO_8859-1.html.tgz
> >
> > This will download the HTML version of the English FreeBSD handbook, and
> > install it under /opt/share/doc (instead of the more usual /usr/share/doc).
> >
> > Now, pkg_add in FreeBSD has hooks to allow post-install scripts to be
> > run, that could call an sk command to update the index. But the sysadmin
> > should also be free to create /usr/local/etc/scrollkeeper.cf, and make sure
> > that "/opt/share/doc/" is listed as a directory to be indexed.
> This suggestion does work only if the doc is locally installed, what if
> I point to a page on the web, where the document is?
|
