Re: [Scrollkeeper-devel] ScrollKeeper-0.1 Proposal #3

[Nik C. <ni...@fr...>]

On Mon, Nov 13, 2000 at 11:45:26AM -0600, Dan Mueth wrote:
> > You probably don't know where the application is going to be installed until
> > install time, not build time.  Using the FreeBSD ports tree, it's trivial
> > to do
> > 
> >     cd /usr/ports/foo/bar
> >     make
> >     make PREFIX=/somewhere/else install
> > 
> > Similarly, if you're building packages on BSD (or RPMs, or whatever) the
> > end user can change the install path after the package has been built, but
> > before it has been installed.
> 
> 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).

> so that the path of the doc was given to ScrollKeeper at install
> time.  This would solve the problem of paths changing between build and
> install time.  However we decided to change the process to simplify things
> for developers and packagers.  (see the mailing list archives...)

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.

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.

> I would expect that changing the install path of a package after it is
> built would often wreak havoc on it.  Do people really do this very often,
> and are most packages robust against this?  (ie. Do we really have to
> worry about this?)

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.

> > Your examples don't use a sufficiently long <locale>.  For example, the user
> > might install docs in Chinese, using both EUC and Big 5 encoding.  For that,
> > you really need to be able to specify zh_CN.EUC and zh_TW.Big5.
> > 
> > Note that trying to rely on just zh_CN or zh_TW isn't sufficient for other
> > languages, like Japanese, where the various encodings hang off a ja_JP
> > prefix.
> 
> I don't think long locales pose any problems.

As long as people are aware of the issue, that's all.

N
-- 
Internet connection, $19.95 a month.  Computer, $799.95.  Modem, $149.95.
Telephone line, $24.95 a month.  Software, free.  USENET transmission,
hundreds if not thousands of dollars.  Thinking before posting, priceless.
Somethings in life you can't buy.  For everything else, there's MasterCard.
  -- Graham Reed, in the Scary Devil Monastery