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

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

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

>>    - 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,
Matthew Johnson

Attachment: signature.asc
Description: Digital signature

Reply to: