[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Fwd: 'knopflerfish-osgi' uploaded to mentors.debian.net]

Hi Matthew,

thanks for the review. Some questions back (if I removed your remark, I just accepted it).

Matthew Johnson wrote:
   - there is a debian/patches/debian-changes* patch which has been
     autogenerated by dpkg-source. Looks like the clean target doesn't remove
Sorry, I oversaw this one.

- 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...

   - you have pre-built javadoc in the source package. You must rebuild it
     before installing, so we normally recommend stripping it from the source
     tarball, given you are repacking already

   - you only list BSD licence in debian/copyright, but there are some apache
licenced files (eg, but not an exhaustive list: ./knopflerfish.org/docs/jars/useradmin/useradmin_all-2.0.2/src/org/osgi/service/useradmin/User.java

   - you don't appear to have a -doc package or install the javadoc in the
     main package. It is highly recommended to do so
> grep -R 'http://www.apache.org/licenses/LICENSE-2.0' . reveals 366 files
>      referencing the apache licence.
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?

And I trusted the NOTICE.txt from upstream, because it seemed pretty well complete. OK, need to do a licensecheck...

   - 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?

And I know the answer, so don't take it personally: because the Java Policy doesn't reflect the lived reality! Fine, but then update the Java Policy! Since years have different people said that they will do it, and nothing ever happened.

My answer to this is to respect the policy but to put Sun's JRE in front to avoid as much as possible incompatible dependencies.

Speaking of policy, the virtual package lists states: "Packages MUST NOT use virtual package names (except privately, amongst
a cooperating group of packages) unless they have been agreed upon and
appear in this list."
I don't think that the Java packages can be called private but we have java-runtime, java5-runtime, java6-runtime (plus headless variants). Not forgetting java-sdk, java2-compiler, java2-sdk, java5-sdk, java6-sdk. And let us also not forget the gcj/gij stuff, which provides the above inofficial virtual packages without actually being fully compatible with Java.

So, who is not respecting the policy here?

Thanks, Eric

Reply to: