(debian-devel stuff halfway down**)
> From: Stephane Bortzmeyer <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED]
