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 / --------------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
