FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 03-26-2010, 08:15 AM
Matthew Johnson
 
Default 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
 
Old 03-26-2010, 09:33 AM
Matthew Johnson
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

On Fri Mar 26 11:24, Vincent Fourmond wrote:
> > *Programs and libraries &should; enable JUnit tests, if these are present.
> > **However, these tests &should; not lead to build failures unless
> > Maintainer is confident enough that tests are stable between builds*
>
> I think we are missing the point here; for instance, I've mostly
> disabled junit tests because they depend on not-yet-packaged or even
> non-DFSG-free libraries. I think both formulations are too oriented
> towards: "junit tests should be enabled unless they fail", which
> basically defeats the purpose of any test suite. I think we don't need
> any comment about build failures: "should" is weak enough that a
> maintainer could disable it if he/she thinks there are good reasons to
> do so.

I believe the default was 'off' because having transients which aren't actually
problems causing the build to fail on a buildd is bad. I certainly agree with
Damien's phrasing, if you are sure they are fine then you can have them cause
the build to fail, but you should actively be thinking in that direction.

Matt

--
Matthew Johnson
 
Old 03-26-2010, 12:36 PM
Matthew Johnson
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

On Fri Mar 26 13:09, Thomas Koch wrote:
> There are two questions I had about Debian-Java unit tests and which I propose
> to answer in the policy:
>
> - Is there any time limit, how long unit test suites may take?

Not specifically, but it's considered bad form if it's the majority of the
buildtime. Less applicable to arch-all packages, but remember the arch-any
packages will be built on the buildds of slow architectures. Build-time tests
should not be a complete test suite, but more a touch-test to see whether it's
generally ok.

> - Is there anything I've to take care of, what a unit test may not do on a
> build server? Like accessing the internet, connecting to localhost?

You certainly can't rely on internet access and starting any kind of local
server is a little dodgy, particularly if it doesn't do random port selection.

This isn't a java-policy-specific issue, if it should be addressed anywhere
it's more suitable to the dev-ref than policy.

Matt

--
Matthew Johnson
 
Old 03-26-2010, 03:37 PM
Eric Lavarde
 
Default Integrating the FOSDEM 06 Draft into the Java Policy

Hello,

Matthew Johnson wrote:
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

I have some problems with this:

1. the policy states something like "javaX-runtime fulfills the Java X
specifications" (sorry, the patches are not reachable right now), but
gcj/gij specifically does not fulfill the Java X specifications (else
they wouldn't be incompatible with sun's Java resp. openjdk).


2. On one side, in order to depend on default-j, programs and libraries
must work both with openjdk and gcj, such programs/libraries should then
depend on default-j, and only such programs/libraries can depend on
javaX-runtime. The result is that javaX-runtime and default-jre are more
or less interchangeable, and only confuse people (well, me at least).


3. gcj's versioning doesn't follow Java's versioning (X), so that each
new version of gcj is just a more and more complete version of any X
version of Java.
Example: package MyJavaProgram depends on gcj-jre (>= 4.4) |
javaX-runtime because it doesn't work with gcj 4.3. But user already has
gcj-jre=4.3, which also provides javaX-runtime --> failure.


4. On the other hand, openjdk and sun's java are really interchangeable
and would justify a javaX-runtime, as their own versioning/naming
follows the X schema.


Bottom-line, I would ask to either suppress javaX-runtime all together
as being useless or even dangerous (as per point 3), or (my preferred)
to reserve it for runtime environments which have passed the Java
Compatibility Tests.


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.

From my own experience, I know it that I check what upstream says (Java5),
I compile it with OpenJDK6, and then it doesn't work with Java5 anymore.
But that's probably mostly wording, bottom line, both _must_ be aligned.

Thanks, Eric


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BACE2B4.4060605@zorglub.s.bawue.de">http://lists.debian.org/4BACE2B4.4060605@zorglub.s.bawue.de
 

Thread Tools




All times are GMT. The time now is 12:08 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org