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
knopflerfish-osgi-2.3.3/knopflerfish.org/osgi/framework/resources/tstamp
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: