On Sat, Nov 10, 2001 at 01:08:42PM +0100, Max Kellermann wrote: > On 0, Ola Lundqvist <[EMAIL PROTECTED]> wrote: > > I have now read this. Not very much of a documentation so I have some > > questions... :) > > > > The Class-Path:-thing. Is it per Name: (class) or per jar-file? > > > What exactly do you mean with "Name: (class)" ? > > > > > This whole thing seems to me very broken, like an idea of sales guys. It's > > > > s/me very broken/be an applet thing/; > > > True, for applets this might be a tolerable idea :-) > > Sometimes I think Sun forgets about all the people who write Java > application, while they are hyping applets, servlets, J2EE etc. Does anyone > still remember Jini? What has happened to that "revolution"? > > > > * NO directories in the Class-Path: statement. Just the jar-file. > > Every jar must be in /usr/share/java so that should not be a problem. > > > > The jar name should be the one that it really depends on. We have a > > problem here that we can not say things like. > > Class-Path: xerces.jar (>= 1.0.3). > > > > So we should do like Class-Path: xerces-1.jar > > > No Class-Path at all whenever possible.. remember the example that Xalan2 > provides a Xalan1-compatibility layer - it Xalan2 must be included, we can > satisfy all Xalan1-dependencies with that library (with lower precedence). > Not possible with Class-Path because the JVM adds the Classpath, not us. >
Ok, but what will happen to the applet-developers? Will it work anyway? > > * The deb maintaner have to be the one responsible for the information > > in the mainfest file. We should of course use information provided > > by the upstream developer but the maintainer have to make sure that > > it follows the policy. > > > This only applies if we decide to use the manifest file. If we don't use it, > we try not to care about it. > > > > Not too paranoid. But is this solvable at all? To me it seems unsolvable > > so let us not adress this too much. The alternative is to say: > > This kind of stuff does not work, so let us not even try (at program start). > > > It is solvable. There may be applications which can't be started because > dependencies cannot be met without producing conflicts. Well, nice that > Debian tells me before I lose my data. If the dependency checker is wrong, > it's either a bug in the dependency checker or the package maintainer filled > out wrong infor - both can be fixed. The gray zone where the application runs > fine, but the dependency checker forbids, well, maybe the application works, > but it is totally undefined. We have to work towards fine grained > dependencies where 'generate_classpath' has much power to move stuff around. > I believe it will work. > > > > Some debhelper tools should be very nice: > > > > * One that reads the manifest (or some other more general database) > > and give some dependency information. > > * One that sign jars (and such stuff). > > * One that fixes the manifest from some more general information. > > * One that takes the source and generates a dependency line. It should > > be possible. :) At least suggest some dependencies. > > > I will try to write a small demonstration of my classpath generator script > and JAR dependencies. Maybe that's a good point to start. That is probably a good place to start, yes. :) Regards, // Ola PS. You forgot the list again. :) DS. > Regards, > Max -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
