Re: FreeMind and gcj [Re: Help needed on the Java policy]
On Jan 29, 2008 5:18 PM, Eric Lavarde <[EMAIL PROTECTED]> wrote: > I can log a bug along these lines if you want but someone will have to > dig into it, because, without error message, I don't know where to start. You could start by updating this page: http://developer.classpath.org/mediation/FreeSwingTestApps or if it's only AWT: http://developer.classpath.org/mediation/FreeAWTTestApps Egon -- http://chem-bla-ics.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
Andrew Vaughan writes:
> If you are going to rework the virtual packages, please consider adding
> -nox packages so that java{,5}-runtime can depend the appropriate X windows
> packages, and server apps that don't need X windows can depend on
> java{,5}-runtime-nox.
see java-gcj-compat-headless, currently in NEW.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
On Wed, Jan 30, 2008 at 05:08:45AM +1100, Andrew Vaughan wrote:
> Hi
>
> On Wednesday 30 January 2008 04:11, Matthew Johnson wrote:
> [snip a lot of good stuff I agree with]
> > A much better solution would be to define a better set of virtual
> > packages. I would go with:
> >
> >- lowest common denominator (essentially the _intersection_ of Java
> > 1.4 and whatever java-gcj-compat supports)
> > Every RE can provide this.
> >- sun java 1.5-derived
> > This would be provided by sun*jre, icedtea, anything produced
> > by java-package.
> >
> > Possibly java-runtime and java5-runtime?
> >
> > Packages would then either depend on: java-gcj-compat | java-runtime OR
> > {icedtea,sun-java5-jre} | java5-runtime
>
> If you are going to rework the virtual packages, please consider adding
> -nox packages so that java{,5}-runtime can depend the appropriate X windows
> packages, and server apps that don't need X windows can depend on
> java{,5}-runtime-nox.
The X packages should only be in Recommends and its possible to not
install Recommends (but you are expected you are knowing what you are
doing).
Cheers,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
On Tue, Jan 29, 2008 at 09:47:53PM +0100, Eric Lavarde wrote: >> no. > OK, Why no and why is "Recommends" sufficient? If I may interpret your > answer, it's because you don't want to pull X-stuff when you only want > to have a Java runtime for your server. > In this case, the proposal from Andrew Vaughan to have a javaN-runtime > and a javaN-runtime-nox would make much sense, wouldn't it? > > There would then be a sun-javaN-jre and a sun-javaN-jre-nox (for > example), and the same for gij/gcj/compat... Recommends are considered to be installed. When users don't install the Recommends they are on their own and its expected that they know what they are doing. Recommends are installed by default so its no problem >>> 3. to gij again because, even after installation of libgcj9-0-awt, >>> FreeMind doesn't work properly with it. >> >> maybe. please file an upstream report, then file a bug report in >> debian and mark it as forwarded. >> >> >>Maybe having the sun-java[56] in debian is a mistake. It misleads >>people (even maintainers like you) to just use these, and not care >>about the free java stack. Keep in mind that there's only a >>handful of people involved in java packaging in debian (sorry if I >>did miss someone). >> > I do not agree, I do care, else I wouldn't suggest the above changes to > the Java policy, but if my package doesn't work with gij, it just > doesn't work, and I still expect that I get a workable solution for my > package, with a finite amount of complexity. > > > I'm trying to be constructive, but if it comes down to "we only care > about free java and server apps", then I just remove java2-runtime from > my dependencies and end of the discussion. > We do care about GUI apps. We just dont care much about non-free software. Bug reports improve the free stack so it good to get them from users. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
Hi, Matthias Klose wrote: Eric Lavarde writes: Hi everybody, thanks for your answers, it looks like we don't have yet a consensus. Let me try to suggest one. POINT 1: I would suggest to modify the Java Policy along these lines: - the specific java runtimes listed before java(2)-runtime are the ones tested by the packager, and for which he's ready to stand up and make it work (the supported runtimes). - if a bug report is related to another java runtime and the bug can't be reproduced under the "supported" runtimes, the maintainer may reassign the bug report to the "faulty" runtime package. If there is a consensus on this one, I'll file a patch on java-common. these packages having a last alternative dependency on '| java2-runtime' Yeah, sorry, that's what I meant. POINT 2: I will duplicate the bug I got on FreeMind in 4 and forward them as follows: 1. to sun-java5-jre and sun-java6-jre because they miss the X-library dependencies, it can't be that my package has to depend on those in order to work (how should I know which ones are required?). for now, see the Recommends of that package. 2. to gij because it provides java2-runtime but doesn't provide the AWT library. no. OK, Why no and why is "Recommends" sufficient? If I may interpret your answer, it's because you don't want to pull X-stuff when you only want to have a Java runtime for your server. In this case, the proposal from Andrew Vaughan to have a javaN-runtime and a javaN-runtime-nox would make much sense, wouldn't it? There would then be a sun-javaN-jre and a sun-javaN-jre-nox (for example), and the same for gij/gcj/compat... 3. to gij again because, even after installation of libgcj9-0-awt, FreeMind doesn't work properly with it. maybe. please file an upstream report, then file a bug report in debian and mark it as forwarded. Maybe having the sun-java[56] in debian is a mistake. It misleads people (even maintainers like you) to just use these, and not care about the free java stack. Keep in mind that there's only a handful of people involved in java packaging in debian (sorry if I did miss someone). I do not agree, I do care, else I wouldn't suggest the above changes to the Java policy, but if my package doesn't work with gij, it just doesn't work, and I still expect that I get a workable solution for my package, with a finite amount of complexity. I'm trying to be constructive, but if it comes down to "we only care about free java and server apps", then I just remove java2-runtime from my dependencies and end of the discussion. Eric Matthias [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436206 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
Hi
On Wednesday 30 January 2008 04:11, Matthew Johnson wrote:
[snip a lot of good stuff I agree with]
> A much better solution would be to define a better set of virtual
> packages. I would go with:
>
>- lowest common denominator (essentially the _intersection_ of Java
> 1.4 and whatever java-gcj-compat supports)
> Every RE can provide this.
>- sun java 1.5-derived
> This would be provided by sun*jre, icedtea, anything produced
> by java-package.
>
> Possibly java-runtime and java5-runtime?
>
> Packages would then either depend on: java-gcj-compat | java-runtime OR
> {icedtea,sun-java5-jre} | java5-runtime
If you are going to rework the virtual packages, please consider adding
-nox packages so that java{,5}-runtime can depend the appropriate X windows
packages, and server apps that don't need X windows can depend on
java{,5}-runtime-nox.
Andrew
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
I've been lurking on this thread up until now, but wanted to chime in to say
that I agree with Matthew's point:
> If something _does not work at all_ with the free VMs I don't think it
> should depend on java2-runtime.
Whether or not a package works with a free VM is an issue for the maintainer
to resolve, including filing the appropriate bug reports, etc. Obviously
the motivations behind the idea of always including java2-runtime as a
dependency are good - i.e. that we want to improve the free VMs as much as
possible, to the point where these packages can depend on java2-runtime.
But requiring java2-runtime to be listed as a dependency in the archive
package simply pushes this problem off to the users, who will rightfully
file bugs when the software installs but fails to operate.
I'd propose that we set the the dependencies for the upload to the archive
to something that will always work for the user, and then take some action
to make sure that the maintainer is well aware of his or her responsibility
to aid in the improvement of the free VMs. Perhaps a reminder email
generated for those packages with dependencies on non-free VMs could be sent
out on an automated basis - say, when there are updates to the free VM
packages. The upload would suggest that new testing with the free VMs
should occur, bugs should be updated, etc. I think the key issue here is
that without some mechanism in place, the it's easy for the maintainer to
forget about re-testing with the free VMs.
0.02,
tony
Matthew Johnson wrote:
On Tue Jan 29 17:45, Eric Lavarde wrote:
POINT 1:
I would suggest to modify the Java Policy along these lines:
- the specific java runtimes listed before java(2)-runtime are the ones
tested by the packager, and for which he's ready to stand up and make it
work (the supported runtimes).
- if a bug report is related to another java runtime and the bug can't be
reproduced under the "supported" runtimes, the maintainer may reassign the
bug report to the "faulty" runtime package.
The problem here, and what I disagree with, is that just because you
list them first, does not mean they get installed when you install the
package, nor that they are used when the user run it. I am strongly of
the opinion that whether `apt-get install package' produces something
which works should not depend on what you already have installed.
I think the problem here is partly a bad definition of `doesn't work'
and what java2-runtime is for.
I will also clarify here that I am only considering things which are in
the archive. All bets are off when you have non-packaged things,
although I'm not objecting to supporting them where possible and when it
doesn't compromise working in the archive.
If something _does not work at all_ with the free VMs I don't think it
should depend on java2-runtime. Firstly, it certainly shouldn't be in
main, since it requires a non-free or unpackaged program to run.
Secondly, even if you put "sun-java5-jre | java2-runtime" in the
depends, most people will already have java-gcj-compat installed, and
hence sun-java5-jre won't be installed, and the program will not work,
despite the depends being satisfied. I think this qualifies for a
Serious bug.
If there is something which _should_ work with java2-runtime, but
doesn't in practice work with any of the free VMs then you could file
bugs on them all and leave the package depending on java2-runtime, but
practically speaking this will still leave most people with an
inoperable program. Hence in practice, I think the definition of
java2-runtime should be `whatever java-gcj-compat supports' and anything
else should list packages explicitly (or, we should add more virtual
packages, see below)
When it is what this seems to be, it does work, it's just a bit ugly and
maybe some small features don't work, that would seem appropriate to
keep in main, but include a note that a different runtime might work
better. Followed, of course, by filing bugs.
A much better solution would be to define a better set of virtual
packages. I would go with:
- lowest common denominator (essentially the _intersection_ of Java
1.4 and whatever java-gcj-compat supports)
Every RE can provide this.
- sun java 1.5-derived
This would be provided by sun*jre, icedtea, anything produced
by java-package.
Possibly java-runtime and java5-runtime?
Packages would then either depend on: java-gcj-compat | java-runtime OR
{icedtea,sun-java5-jre} | java5-runtime
I think this split is warranted given the things we have in the archive
at the moment and the large difference between the free VMs and the
sun-derived ones.
Note that this also applies to the scripts or wrappers used to start the
program. I don't think they should depend on the current alternatives
setting of java, but should still work even if the package only works
with some VMs. I think jarwrapper needs some work to support all the
combinations, but can at least
Re: Help needed on the Java policy
Eric Lavarde writes: > Hi everybody, > > thanks for your answers, it looks like we don't have yet a consensus. > Let me try to suggest one. > > POINT 1: > > I would suggest to modify the Java Policy along these lines: > - the specific java runtimes listed before java(2)-runtime are the ones > tested by the packager, and for which he's ready to stand up and make it > work (the supported runtimes). > - if a bug report is related to another java runtime and the bug can't > be reproduced under the "supported" runtimes, the maintainer may > reassign the bug report to the "faulty" runtime package. > > If there is a consensus on this one, I'll file a patch on java-common. these packages having a last alternative dependency on '| java2-runtime' > POINT 2: > > I will duplicate the bug I got on FreeMind in 4 and forward them as follows: > > 1. to sun-java5-jre and sun-java6-jre because they miss the X-library > dependencies, it can't be that my package has to depend on those in > order to work (how should I know which ones are required?). for now, see the Recommends of that package. > 2. to gij because it provides java2-runtime but doesn't provide the AWT > library. no. > 3. to gij again because, even after installation of libgcj9-0-awt, > FreeMind doesn't work properly with it. maybe. please file an upstream report, then file a bug report in debian and mark it as forwarded. Maybe having the sun-java[56] in debian is a mistake. It misleads people (even maintainers like you) to just use these, and not care about the free java stack. Keep in mind that there's only a handful of people involved in java packaging in debian (sorry if I did miss someone). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
On Tue Jan 29 17:45, Eric Lavarde wrote:
> POINT 1:
>
> I would suggest to modify the Java Policy along these lines:
> - the specific java runtimes listed before java(2)-runtime are the ones
> tested by the packager, and for which he's ready to stand up and make it
> work (the supported runtimes).
> - if a bug report is related to another java runtime and the bug can't be
> reproduced under the "supported" runtimes, the maintainer may reassign the
> bug report to the "faulty" runtime package.
The problem here, and what I disagree with, is that just because you
list them first, does not mean they get installed when you install the
package, nor that they are used when the user run it. I am strongly of
the opinion that whether `apt-get install package' produces something
which works should not depend on what you already have installed.
I think the problem here is partly a bad definition of `doesn't work'
and what java2-runtime is for.
I will also clarify here that I am only considering things which are in
the archive. All bets are off when you have non-packaged things,
although I'm not objecting to supporting them where possible and when it
doesn't compromise working in the archive.
If something _does not work at all_ with the free VMs I don't think it
should depend on java2-runtime. Firstly, it certainly shouldn't be in
main, since it requires a non-free or unpackaged program to run.
Secondly, even if you put "sun-java5-jre | java2-runtime" in the
depends, most people will already have java-gcj-compat installed, and
hence sun-java5-jre won't be installed, and the program will not work,
despite the depends being satisfied. I think this qualifies for a
Serious bug.
If there is something which _should_ work with java2-runtime, but
doesn't in practice work with any of the free VMs then you could file
bugs on them all and leave the package depending on java2-runtime, but
practically speaking this will still leave most people with an
inoperable program. Hence in practice, I think the definition of
java2-runtime should be `whatever java-gcj-compat supports' and anything
else should list packages explicitly (or, we should add more virtual
packages, see below)
When it is what this seems to be, it does work, it's just a bit ugly and
maybe some small features don't work, that would seem appropriate to
keep in main, but include a note that a different runtime might work
better. Followed, of course, by filing bugs.
A much better solution would be to define a better set of virtual
packages. I would go with:
- lowest common denominator (essentially the _intersection_ of Java
1.4 and whatever java-gcj-compat supports)
Every RE can provide this.
- sun java 1.5-derived
This would be provided by sun*jre, icedtea, anything produced
by java-package.
Possibly java-runtime and java5-runtime?
Packages would then either depend on: java-gcj-compat | java-runtime OR
{icedtea,sun-java5-jre} | java5-runtime
I think this split is warranted given the things we have in the archive
at the moment and the large difference between the free VMs and the
sun-derived ones.
Note that this also applies to the scripts or wrappers used to start the
program. I don't think they should depend on the current alternatives
setting of java, but should still work even if the package only works
with some VMs. I think jarwrapper needs some work to support all the
combinations, but can at least specify one specific VM.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Re: Help needed on the Java policy
Hi everybody, thanks for your answers, it looks like we don't have yet a consensus. Let me try to suggest one. POINT 1: I would suggest to modify the Java Policy along these lines: - the specific java runtimes listed before java(2)-runtime are the ones tested by the packager, and for which he's ready to stand up and make it work (the supported runtimes). - if a bug report is related to another java runtime and the bug can't be reproduced under the "supported" runtimes, the maintainer may reassign the bug report to the "faulty" runtime package. If there is a consensus on this one, I'll file a patch on java-common. POINT 2: I will duplicate the bug I got on FreeMind in 4 and forward them as follows: 1. to sun-java5-jre and sun-java6-jre because they miss the X-library dependencies, it can't be that my package has to depend on those in order to work (how should I know which ones are required?). 2. to gij because it provides java2-runtime but doesn't provide the AWT library. 3. to gij again because, even after installation of libgcj9-0-awt, FreeMind doesn't work properly with it. OK? Thanks, Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FreeMind and gcj [Re: Help needed on the Java policy]
Hi Andrew, Andrew Haley wrote: I guess it depends on whether the program fails because a particular runtime has bugs or because the program depends on something it shouldn't use, such as com.sun.* classes. We're pretty complete with respect to 1.4, so I'd like to know what this problem actually is. Well, I suspect that the classpath team and associated do concentrate their effort on the non-AWT/Swing classes because Apache/Server-classes and Eclipse don't use them. In short, FreeMind 0.7.1 (the one in unstable) starts very well with the latest gcj, doesn't spit any error, but is completely unusable (and ugly). I can log a bug along these lines if you want but someone will have to dig into it, because, without error message, I don't know where to start. Eric Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
On Tue, Jan 29, 2008 at 09:47:41AM +, Andrew Haley wrote: > Matthew Johnson wrote: >> >> I have a package which compiles in the sid java-gcj-compat-dev, but only >> runs with sun java (or, I assume, IBM, but since IBM isn't in the >> archive, I don't think it's all that important to cater for). I've filed >> bugs against gcj, which have been fixed upstream, and it will probably >> work with icedtea, but until either of those reaches the archive, I only >> depend on sun-java5 | sun-java6. > > It seems to me like there's something major wrong here. > > Bugs get filed against gcj, I or one of the other gcj maintainers fix them, > but the patches don't get applied to Debian's gcj package. So, despite > the fact that the bug has been fixed, you still have to depend on Sun's Java. If that issue was reported and fixed in GCJ the patch should be in Debian GCJ too. Matthias merges all/most upstream fixes into debian GCJ. Which particular fix we are speaking about? Perhaps some patch was missed. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
Matthew Johnson wrote: I have a package which compiles in the sid java-gcj-compat-dev, but only runs with sun java (or, I assume, IBM, but since IBM isn't in the archive, I don't think it's all that important to cater for). I've filed bugs against gcj, which have been fixed upstream, and it will probably work with icedtea, but until either of those reaches the archive, I only depend on sun-java5 | sun-java6. It seems to me like there's something major wrong here. Bugs get filed against gcj, I or one of the other gcj maintainers fix them, but the patches don't get applied to Debian's gcj package. So, despite the fact that the bug has been fixed, you still have to depend on Sun's Java. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
