On Sun Mar 21 15:31, Eric Lavarde wrote:
> Niels Thykier wrote:
>> Yes, I am guilty here. On a related note, does anyone know if the draft
>> [1] has been ratified or it is just a "proposed" change? If it is the
>> latter then lets get (the parts of) it (we want) approved so I can
>> integrate them.
> Nobody is guilty, and thanks for taking my ranting in a constructive manner.
We should definitely try and get this hammered out. I'm happy to do any changes
or uploads which require a DD.
> I didn't know about this page. How do you want to get comments (should I
> have some after reading)? Would OpenDoc with tracked changes be OK?
Well, it is a wiki..
>> If you put a non-free JVM first in the alternatives your package must go
>> into contrib. It is better to put default-{jre,jdk} or openjdk first and
>> keep the package in main.
>
> Agreed, but I did put openjdk first, Sun's Java is only 2nd; my
On Sun Mar 21 13:18, Eric Lavarde wrote:
> Where is it documented that I should depend on default-jdk or default-jre?
The thing about using default-jdk is that it's available on every platform and
refers to openjdk or gcj-jdk as appropriate, so it's a technical reason. It's
also not a virtual platform I agree it should be in policy.
>>> 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.
My opinion is that openjdk should be superseding sun-java-*, and gcj should be
replacing anything else, which means we have 3 options, works with open, works
with gcj, or works with both. Hence, virtual packages should cover the latter as
the dependency is obvious if it only works with one.
Neils, I thought you had produced a more up-to-date draft than that, which
doesn't seem to have had any significant changes since 2006?
Matt
--
Matthew Johnson
Attachment:
signature.asc
Description: Digital signature