Hi again. > I think we can assume that all libraries work with java2-runtime, at > least I have not seen one that requires java1-runtime and does not work > with "JDK 1.2 and above". The next problem is that java2-runtime means > "JDK 1.2 core classes and above" but there's no way to specify "JDK 1.4 > core classes and above" which is needed in some cases, e.g. > libtomcat4-java. So a dependency on java2-runtime basically tells us > nothing.
Yes it does. It tells us that the lib/app won't work with java1 alone. And there *are* packages in debian that do work with java1 alone, so the use of java2-runtime does convey meaningful information. > > This is because java2-runtime and java1-runtime are very loosely > > specified dependencies. Removing them will not help fix anyone's > > broken java installations. If tomcat4 needs java2 in most cases > > but works with kaffe regardless, why not just add kaffe as an optional > > substitute for java2-runtime in this case, i.e., have tomcat4 depend > > on (kaffe | java2-runtime) ? > > Right, but this not only has to de done for libtomcat4-java but also for > all its dependencies. Hmm? Say A depends on B. If A uses java2 stuff and B does not then only A needs the java2 depends. If B uses java2 stuff and A does not then only B needs the java2 depends - in this case A will need java2 as well to make it run, but this is happily provided automatically by A depending on B. i.e., only the packages that are using java2 stuff *directly* need to worry about this depends line. As in any other parts of debian, dependencies are automatically transitive and you don't need to manually copy indirect dependencies yourself. > > 1) Libraries are not just for use by other debian apps. People use > > them in their own custom software as well. In this case, the only > > place they're going to get the right dependencies is from the library > > package itself. > > I would currently not recommend using the Debian JARs in custom projects > since they might have reduced functionality so they can be in main, e.g. > a missing Swing GUI. Then why bother providing debian packages at all? For some people, the political ideals are part of what draws them to debian. To add a library package to debian and then say "it's broken but we don't care because nobody should use it anyway" is absurd. You must assume that there *will* be people out there who might want to use a debian library in their own projects (since this is both valid and indeed encouraged in terms of software reuse). This means that you must ensure that when a library is installed, all of its requirements are installed also. i.e., a library's dependencies belong with the *library* package, not with the set of all apps that use the library. Of course, this also means that when the library dependencies change there is only one point of modification (the library), not a large number of points of modification (all the individual apps that use it). > > 2) As an application packager, you know what libraries your app uses. > > You shouldn't have to know the external libraries in intimiate detail as > > well - in particular you shouldn't have to chase down what classes are > > used by the libraries but not by your app itself > > I disagree. An application packager is the only one who knows what > external libraries are required. I think you've missed my point. Sure, an application packager needs to know that their app requires libraries X, Y and Z. But they shouldn't need to know that the external library X also requires P and Q, and that Q in turn requires F and G, and so on. i.e., they should just be able to depend on X, Y and Z, and then let the packagers for X, Y and Z work out the indirect dependencies that come as a result of this. > > An example here is > > KDE packaging - you generally build-depend on kdelibs4-dev, but you rely > > on the fact that the kdelibs maintainers have tracked down the multitude > > of other libraries that kdelibs uses for itself that will also need > > to be installed. > > You might also need additional (build) dependencies in case you are > using dynamically loaded plugins. Sure, maybe I need a couple of additional build-depends that aren't part of the usual KDE machinery. But what you're suggesting is IMHO akin to saying that kdelibs should depend on nothing, and that each KDE app should manually track all of the many little libraries that are used internally by kdelibs, even if the app itself doesn't use them directly. I claim this is a lot of duplicated work for application maintainers, but more importantly it's error-prone (especially when kdelibs changes its requirements), and users building their own KDE apps will have no guarantee that their apps will compile since they have no idea what else needs to be installed just to make kdelibs work. > And BTW, we don't have a lot of Java application packages in Debian, > probably around 10. On the other hand, we have well over 50 library > packages and I like to reduce the required time to maintain them. I don't believe that dismantling the dependency system is the correct way to do it. Ben. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
