On Sun Mar 21 13:18, Eric Lavarde wrote: > thanks for the review. Some questions back (if I removed your remark, I > just accepted it). (policy-related changes in the other thread) >> - the other patches aren't listed in the series. Are you using 3.0 >> (quilt) and also simple-patchsys? Don't use two different patch >> systems, it'll just go wrong > Regarding the two above comments, I had understood that I'm not obliged > to use quilt but can stay with my usual patch system, even if I use > version 3.0. > Given the fact that I didn't find any comprehensive (or comprehensible) > documentation about the new format, I admit that I'm more than confused. > Any link would be well appreciated... Ok, that's a fair comment. It _is_ possible to run them both at once - except that you may get double-application when automatic patches start being created? I don't know precisely how simple-patchsys interacts, so it's strongly discouraged. In this case, you can just list your patches in debian/patches/series and remove the simple-patchsys line in debian/rules and everything should Just Work (tm). > To be honest with you, I didn't plan to package the doc at all, because > I saw this package only as dependency for another package, and not > really as development basis for others. > Do you have a fundamental problem with this approach? I can see that argument, but packaging the doc is not a lot of work, particularly with javahelper, and you are bound to get someone asking for it. > And I trusted the NOTICE.txt from upstream, because it seemed pretty > well complete. OK, need to do a licensecheck... Yeah, this is always necessary, upstreams are notoriously bad about this. At least you _can_ ship Apache 2.0 in Debian, it just needs listing in debian/copyright. >> - does knopflerfish really only work with openjdk? If not you should build > Trying to build with gcj didn't work. > >> with default-jdk and have default-jre as the first alternative. If it >> _does_ only work with openjdk then you should not depend on | >> java2-runtime. In any case you don't need to depend on | sun-java5-jre | >> sun-java6-jre given that they provide java2-runtime > OK, if there is one thing that goes really on my nerves since I've > started to package Java stuff for Debian, it is this f*ing Java Policy. > > The policy says: "Java libraries _must_ depend on the needed runtime > environment (java1-runtime and/or java2-runtime) but should not depend > (only suggest) java-virtual-machine." > So, why do you tell me that I _should not_ depend on the runtime? > Where is it documented that I should depend on default-jdk or default-jre? You have a fair point about policy, as addressed in the other thread, and there is some discussion about whether libraries should depend on runtime environments or not, but I wasn't complaining about that. What I do feel very strongly about is that you should not list dependencies which are satisfiable with packages it doesn't actually work with and (less strongly) you shouldn't list duplicates in the dependency list. The other issue is that openjdk is not available on every platform. So, there are 3 cases: - builds and runs with any JDK (in Debian), in which case you should build-depend on default-jdk and depend on default-jre | javaN-runtime, since otherwise the dependencies aren't satisfiable on some architectures (and you must have a concrete dependency on all platforms listed before virtual packages) and all the JREs provide javaN-runtime, so you don't need to specify any others directly - only builds with openjdk, but runs with anything, in which case you should build-depend on openjdk and depend on default-jre | javaN-runtime, for the same reason, although it will only be buildable on some platforms - only builds with openjdk and only runs with openjdk (or sun's VMs from non-free) then you should build-depend on openjdk and depend on openjdk-6-jre | sun-java-6-jre etc, but _not_ on javaN-runtime, since then the dependency is satisfiable with a non-functioning runtime. (I've ignored 'builds with gcj but doesn't run, since I don't think it's useful to be buildable on a platform it can't run) The issue I had was that 1. you build with openjdk which suggests that it can only work with openjdk, in which case the dependency on javaN-runtime is wrong, or that the dependencies on sun-* are redundant, since if no runtime is installed it will always select openjdk, and if they are already installed then javaN-runtime is satisfied. I hope that explains it, Matt -- Matthew Johnson
Attachment:
signature.asc
Description: Digital signature