Andrew Pimlott wrote:
I still feel strongly the sentiment you quoted. A distribution should be a collectionOn Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
But I'll spare you that ranting; let's just say I think it's a horrifically bad idea to have a free-for-all in one's classpath.
I tend to agree, though I should point out that the opposite view has support. For example, Per Bothner said in a previous thread,
In Java we have a global namespace, so the user/developer should not have to specify classpaths etc by default.
(http://lists.debian.org/debian-java/2001/debian-java-200104/msg00014.html)
I mention this because Per qualifies as something of an authority IMO but has not not appeared on this list lately.
of software that works smoothly together. While it may support multiple versions of
packages, we set it up so that users *and* developers by default get the "current stable"
version of all packages, that they work together, and that developers can use installed
"devel" packages without *having* to specify "give me version X.X of package P and
version Y.Y of package Q". We assume that current stable and consistent versions
of header files and libraries are in /usr/include and /usr/lib, and only in exceptional
cases should the user have to add extra -I or _L flags - and certainly not when
using the*installed* current default version of a package. Why should Java be
different? A Java developer should not be asked to specify classpaths for
packages that have been properly installed, unless they *want* (or need) to specify
a particular version. The conclusion is that when a Java package is installed the
default classpath (for all installed supported Java implementations) should somehow
be changed to include the installed package (unless the package is a "compatibility"
or otherwise "non-default" version).
