John Leuner <jewel@pixie.co.za> wrote: > > > > Because it's not compatible with the java-policy. The classes are not > > > in a jar file and they are not in /usr/share/java. So people should > > > put in their classpath /usr/share/classpath/glibj.zip... with all the > > > classes, not only the jta, jdbc-ext or swing. > > I agree - these should be split into the separate jar files so that e.g. > > the swing part can be used by jvms, without using the rest of classpath > > Ok. Do you want these classes to be present both in the classpath .deb > and in the new .deb packages we'll be creating? I think it's the best solution. If you work with classpath, you don't have to install theses packages. If not, you can install them (even if you don't know what classpath is!). > This may have implications for different versions of these classes. > Users may not upgrade all these packages at the same time so they > could have different versions in different places. My opinion is make the separate jar from the classpath source package and don't worry about version problem. Each time you update classpath, the three or four additionnal packages will be upgraded (even if nothing change). I do not think it's a problem. I think just adding a 'fastjar' command to make the additionnal jar's and 'install' them into the separate packages is enough. -- arnaud @ home
Attachment:
pgpeXiDCMY2lo.pgp
Description: PGP signature