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

Re: [Summery] Re: Integrating the FOSDEM 06 Draft into the Java Policy



On Fri Mar 26 09:42, Eric Lavarde wrote:
> Hi Niels,
>
> I have some problems to understand the resulting document, not knowing  
> what the baseline is, but after reading through the patches, I think  
> that the new policy doesn't address the main problem which is the fact  
> that we have 2 incompatible runtime (and compiling/building)  

First I'd like to say that these are not the only patches that Niels will be
applying, we are just going through them on small steps so that simple changes
aren't eclipsed by controversial ones.

> But, from your patches, I understand that javaX-runtime survives and  
> that we add default-jre/jdk (default-j) into the picture, which,  
> depending on the platform, provides either cp-j or java-j, because they  
> pull gcj-j or openjdk-j.

IMO javaX-runtime should be for only things which can work with both:

> A. ones which work with both cp-j and java-j => those ones can and  
> should/must (build-)depend on default-j (easy).

They should build-depend on default-jdk and depend on default-jre | javaN-runtime

> B. ones which work only with cp-j => those can't depend on default-j,  
> should they (build-)depend on gcj-j | some virtual package (which one)?

No, they should build-depend and depend only on gcj, if they only work with
gcj, otherwise the dependency could be fulfilled by a non-functioning runtime.
They should also run with gcj no matter what /usr/bin/java currently points
to, for the same reason.

> C. ones which work only with java-j => those can't depend on default-j,  
> should they (build-)depend on openjdk-j | sun-j | some virtual package  
> (which one)?

Ditto, no virtual package, just openjdk | sun (and build-depends on
specifically openjdk)

> D. ones which work with both cp-j and java-j, but also provide -gcj  
> packages (requiring gcj-j) => do they fall in case A or case B? Or is  
> there a case D?

I think we have decided that there is no good way in the depends system to deal
with -gcj packages. These are option A.

You've also missed out ones where 'work with' is different at compile time and
runtime, but those should be inferable from above.

> As this is the point where I lost my nerves ;-), I think that it's  
> important to have a solution.
>
>
> Less important: it should be precised that a program/library depending  
> on a certain javaX-runtime must make sure that the compilation happens  
> with the -source/-target values corresponding to this X.

Indeed, although I'd specify it the other way around, and if you use javatools,
it will calculate X for you and automatically add it to the dependencies.

-- 
Matthew Johnson

Attachment: signature.asc
Description: Digital signature


Reply to: