Bug#227587: [PROPOSAL] Java library dependencies
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. :)
Reply to: