Suggestion: Post-installation README file (Was: The problem of core classes for Java compilers)
(debian-devel stuff halfway down**)
> From: Stephane Bortzmeyer <bortzmeyer@debian.org>
> Jikes has a problem with core classes. It can use those of the JDK or those of
> kaffe (which allows it to stay free) but is is necessary to tell it where to
> find them.
>
> ...
> Which means you cannot compile even the smallest program without setting
> CLASSPATH to indicate where it can find core classes.
> <http://www.research.ibm.com/jikes/jikes.htm#jikespath> directly violates
> Debian policy about environment variables.
What was the purpose of that policy? Rather, why is it such a strong
policy, apparently not being just a guideline for when it works well)?
Most of Unix is based on configuring or controlling things with
environment variables. Things (e.g., Sun's JVM) are designed with
that in mind. When there aren't appropriate defaults before the
user has set them (e.g., with an environment variable), forcing
some default probably isn't a good idea.
Remember how Sun's JDK loads(ed?) on Windows: You install using an
installer. There is no option to install manually, so you don't know
what registry settings are made. Because of that, you can't reliably
have two versions installed at the same time. (It seems to work, but
you don't know what interactions there might be.)
Two versions should be able to co-exist and even run at the same time,
since two different processes can have different environment variable
settings. It's kind of hard to have process-specific settings in the
global file system.
**
You know, I wonder if automatic package installation has gone slightly
too far.
I think something has been forgotten: pointing users to whatever they
might need and/or want to do after installing a package.
When you install from a tar file, there's README file. After the
installation instructions, it usually mentions what you can do next.
(E.g., it typically mentions the commands provided be the software;
whether the documentation is manual pages, info pages, other files;
etc.)
On the other hand, when you install a package, once the package is
installed, you're kind of left with nothing.
Think about it: You find out about a package and install it on your
system. Now what? What do you do next? How do you know which commands
or user-level files it provides?
There no standard /usr/doc/<package>/README (or README.debian) that
you can count on. There is nothing (standard) pointing to commands or
user-level files provided by the package, or pointing to documentation.
(When there is a file /usr/doc/<package>/README, it's usually from the
original source release and doesn't apply to Debian's packaging of the
software.)
Maybe each Debian package should have a standard post-installation README
file that:
- mentions what the package provides (e.g., commands available to be run,
daemons started, files (e.g., debian-doc).)
(Note that the name of a package isn't always related the command(s) it
provides.)
- refers to configuration options that you're likely to want to change
(I'm not suggested much redundancy with other documentation; just
pointers to things that are especially import or that users are
especially likely to want to know about up front.)
- points to relevant documentation (manual, info, or web pages loaded by
the package, or on-line documentation, etc.)
(Because documentation comes in many forms, it is scattered about
and the user has to check many possibilities (e.g., man <command name>,
man <package name>, man <config. file name>, info <command name>,
/usr/doc/<package name>/.../*.html, /usr/doc/<package_name>/*.txt.gz,
http://..., etc.)
- * points out significant Debian-specific changes to the package
(So if you knew the unpackaged version of the software, you can
know what's different (e.g., Debian's Netscape wrapper that wasted
a lot of my time because its changed behavior wasn't documented).)
Generally, the README file would be a guide to getting on with using
the just-loaded package that could be found easily in a known location
(/usr/doc/share/<package>/README or somewhere).
Daniel
--
Daniel Barclay
dsb@smart.net
Reply to: