-
Enhancement
-
Resolution: Won't Fix
-
P2
-
None
-
7
-
generic
-
linux
The current set of Java RPM packages are designed to work very nicely on JDS R-3 (SuSE 9.1) and Red Hat AS 2.1. They work fairly well with most other versions of SuSE and Red Hat/Fedora, although there can be issues with GNOME and other desktop integration. Many other Linux distributions are also similar to Red Hat and SuSE. For the most part, the Java RPM packages manage to install these systems as well, but again, the quality of the Java integration with other system tools, and the adherence of the Java packages to conventions used by the given distributor is generally considered sub-par by the community.
The primary reason for these problems is the wide range of variability on Linux. Linux is not a single product controlled by a single source with an overall vision. Because of this, it is not unusual for different distributors to do things slightly different from each other. It is even fairly common for there to be significant changes in where and how system level files are placed within two releases from a single vendor!
A method should be found for distributing Java that more readily allows installation and integration on any Linux distribution. Some possibilities for this might include one or more of the following:
* some type of install properties file that the RPM packages can read, which vendors/users customize for their system.
* some type of engine that takes a default Java RPM package as input, and spits out a vendor/user tailored package
* break the Java RPM packages into smaller components that include base Java components, and optional integration components. Typically, it is only the integration that varies so much. It should be possible, without making any changes to the existing license, to provide vendors/users with the fully built base components, and the RPM spec file (an RPM build script) that provides a "reference implementation" for the integration components.
* modify the existing license in a way that allows the Linux community to build and distribute Java as they see fit. This option is actually the best option. It provides the most flexibility, which is highly valued by the Linux community. Changes in the license should guaranty the integrity of the platform, but allow for any form of distribution within that limitation. (Guarantying the platform consists of things such as requiring the JDK/JRE include specific components that are in specific well-known locations that, which at a minimum are relative to JAVA_HOME, but may actually specify JAVA_HOME. Other considerations such as naming schemes and a package's "provide" statements may be necessary.)
* some method of installation other than RPM
The primary reason for these problems is the wide range of variability on Linux. Linux is not a single product controlled by a single source with an overall vision. Because of this, it is not unusual for different distributors to do things slightly different from each other. It is even fairly common for there to be significant changes in where and how system level files are placed within two releases from a single vendor!
A method should be found for distributing Java that more readily allows installation and integration on any Linux distribution. Some possibilities for this might include one or more of the following:
* some type of install properties file that the RPM packages can read, which vendors/users customize for their system.
* some type of engine that takes a default Java RPM package as input, and spits out a vendor/user tailored package
* break the Java RPM packages into smaller components that include base Java components, and optional integration components. Typically, it is only the integration that varies so much. It should be possible, without making any changes to the existing license, to provide vendors/users with the fully built base components, and the RPM spec file (an RPM build script) that provides a "reference implementation" for the integration components.
* modify the existing license in a way that allows the Linux community to build and distribute Java as they see fit. This option is actually the best option. It provides the most flexibility, which is highly valued by the Linux community. Changes in the license should guaranty the integrity of the platform, but allow for any form of distribution within that limitation. (Guarantying the platform consists of things such as requiring the JDK/JRE include specific components that are in specific well-known locations that, which at a minimum are relative to JAVA_HOME, but may actually specify JAVA_HOME. Other considerations such as naming schemes and a package's "provide" statements may be necessary.)
* some method of installation other than RPM