Tom Marble <[EMAIL PROTECTED]> wrote: > Walter Landry wrote: > > [...] > > All of the examples given above are good, but libgetenv-java is about > > as clear as you can get. It only depends on java2-runtime and libc, > > and it serves as a replacement for java.lang.System.getenv. It > > creates a hybrid implementation. > > > > If you want to argue that it is the other packages fault, go ahead. > > That would make the java2-runtime virtual package much less useful, in > > which case there should be a java2-runtime-free virtual package. > > Obviously making sun-java5 not provide java2-runtime (or whatever > provides Debian Java Policy settles upon) defeats the purpose > of packaging Sun Java.
Not really. Having sun-java5 provide java2-runtime only allows other Debian packages to use sun-java5 without special casing. Users can still manually specify everything needed to compile and run programs. That is a big improvement over the current situation. In any case, a package can still use a Depends: line like Depends: java2-runtime | sun-java5-jre if there is no conflict between what the package does and the DLJ. > I appreciate your trying to address an entire class of problems, but > in the case of libgetenv-java it appears that the jar is malformed. > We're it formed correctly it would be in it's own namespace. The problems persist even if it is in its own namespace. In any case, it may well be that libgetenv-java is buggy. Fixing it should not suddenly cause a license problem. There are still all of the packages libcharva1-java libcommons-*-java libregexp-java which have dependencies that are fulfilled by java2-runtime. liboro-java should probably depend on a java2-runtime as well. Finally, can Debian rely on your statements as official statements of Sun, or must Debian only look to the DLJ and DLJ FAQ? Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
