Re: Help needed on the Java policy
Hi, Michael Koch said: > I'm currently working on a proposal for cleaning up the virtual package > chaos. Please give me some more days for this. Fair enough, let's consider as a warm up for the discussion that will come once you'll show your proposal ;-) Thanks, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- 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 14:20, Eric Lavarde - Debian wrote: > Hi, > > Michael Koch said: > > On Wed, Jan 30, 2008 at 09:32:46AM +0100, Eric Lavarde - Debian wrote: > >> - the Java Policy should state that a Java package should depend on > >> java2-runtime only if the packager expects its program to work with a > >> classpath-alike implementation of Java. > >> (what about IcedTea then?) > > > > IMO all java packages should depend on java2-runtime as second > > alternative and bugs should be filed against runtimes not working > > properly with a package. > Oookay... Looks like we're doing circles here. How do we progress now? > I'm fine with both options, but I feel that we need a consensus within > debian-java, and that we don't have it yet. I think we should hammer out a new set of virtual packages (I think Michael is planning on sending an email on that subject) so that we have a situation which better fits both the points of view, and then update the policy to match that. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Help needed on the Java policy
On Wed, Jan 30, 2008 at 02:20:59PM +0100, Eric Lavarde - Debian wrote: > Hi, > > Michael Koch said: > > On Wed, Jan 30, 2008 at 09:32:46AM +0100, Eric Lavarde - Debian wrote: > >> - the Java Policy should state that a Java package should depend on > >> java2-runtime only if the packager expects its program to work with a > >> classpath-alike implementation of Java. > >> (what about IcedTea then?) > > > > IMO all java packages should depend on java2-runtime as second > > alternative and bugs should be filed against runtimes not working > > properly with a package. > Oookay... Looks like we're doing circles here. How do we progress now? > I'm fine with both options, but I feel that we need a consensus within > debian-java, and that we don't have it yet. I'm currently working on a proposal for cleaning up the virtual package chaos. Please give me some more days for this. 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, Michael Koch said: > On Wed, Jan 30, 2008 at 09:32:46AM +0100, Eric Lavarde - Debian wrote: >> - the Java Policy should state that a Java package should depend on >> java2-runtime only if the packager expects its program to work with a >> classpath-alike implementation of Java. >> (what about IcedTea then?) > > IMO all java packages should depend on java2-runtime as second > alternative and bugs should be filed against runtimes not working > properly with a package. Oookay... Looks like we're doing circles here. How do we progress now? I'm fine with both options, but I feel that we need a consensus within debian-java, and that we don't have it yet. > >> - in the words of Michael: >> Michael Koch said: >> > 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). >> >> Can we get an agreement on those points? > > Thats already fact. Do we need our own consensus in Debian Java? No, fine with me, I've closed my "serious" bug on this basis :-) Thanks, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FreeMind and gcj [Re: Help needed on the Java policy]
Eric Lavarde wrote: 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. I think this will come as a terrible shock to those people who spent so much time writing the GUI stuff. 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). Ah, OK, so we're talking about AWT bugs. I admit I don't know very much about that side of Classpath. The notion that Classpath "doesn't care" about non-server applications seems to be very common on this list. Andrew. -- 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 09:32:46AM +0100, Eric Lavarde - Debian wrote: > Hi everybody, > > OK, second try at getting a common understanding: > > - the Java Policy should state that a Java package should depend on > java2-runtime only if the packager expects its program to work with a > classpath-alike implementation of Java. > (what about IcedTea then?) IMO all java packages should depend on java2-runtime as second alternative and bugs should be filed against runtimes not working properly with a package. > - in the words of Michael: > Michael Koch said: > > 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). > > Can we get an agreement on those points? Thats already fact. Do we need our own consensus in Debian Java? 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 everybody, OK, second try at getting a common understanding: - the Java Policy should state that a Java package should depend on java2-runtime only if the packager expects its program to work with a classpath-alike implementation of Java. (what about IcedTea then?) - in the words of Michael: Michael Koch said: > 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). Can we get an agreement on those points? Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]
Re: Help needed on the Java policy
Michael Koch wrote: On Sun, Jan 27, 2008 at 08:35:22PM +0100, Eric Lavarde wrote: Hi, I'm fighting a bit with the current state of the Java policy, and it has hit pretty hard because FreeMind isn't in testing anymore because of this (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436206). OK, starting from the beginning: 1. FreeMind 0.7.1 works only with Sun's Java (let's assume 1.4 only for the sake of simplicity). 2. i.e. I make my package depend on j2re1.4 | java2-runtime, the first is necessary, the second is given by the policy. 3. the issue is that anybody can then decide to fulfill the dependency by installing whatever provides java2-runtime, even if I perfectly know that it won't work. So, how can I fix this and respect the policy? Additional question: the Java RE packages created with java-package used to depend on some X libraries, the sun-javaN-jre packages don't anymore. What is the dependency one should best use for Java programs with an (X-)Gui? Personally I would just depend on some working runtime and on java(2)-runtime and then forward all bugs specific to some runtime to the affected runtime. This help to gets the runtimes fixed. Otherwise they will never get fixed because people dont know the problems. 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. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
On Mon Jan 28 10:40, Michael Koch wrote: > Personally I would just depend on some working runtime and on > java(2)-runtime and then forward all bugs specific to some runtime to > the affected runtime. This help to gets the runtimes fixed. Otherwise > they will never get fixed because people dont know the problems. > > In your case just depending on all the SUN JDK variants seems wrong. Do > you know that the IBM variants dont work? How do you know that no > (future) classpath-based runtime will work? What about icedtea? > However, depending on java2-runtime ensures that anyone who already has a free runtime installed, but not sun runtime (I would guess at quite a large proportion of installs), will not get a working program by doing `apt-get install program'. This seems to me to fundamentally the point of the depends system and would seem to not meet policy 3.5: "Every package must specify the dependency information about other packages that are required for the first to work correctly." or 7.2: "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." I would certainly file a serious bug on any package which did not work after running `apt-get install package'. Personally I would as the package maintainer test with any new runtime which was uploaded to the archive and check whether it is supported. While you could say that packages which provide java2-runtime and don't work with programs which run under sun java 1.4 are themselves buggy, it seems to me that since sun java has never been in main, what we are really considering is compatibility with the free `1.4 compliant' VMs. Were we to change to the virtual depends which were suggested elsewhere of free-java and non-free-java, I would be happy depending on non-free-java in this case, but again to be uploaded to contrib, only if it worked with sun-java6 and sun-java5. Otherwise the (imo) invariant that using only the Debian archives satisfying the build-depends results in a working program is broken. 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. I wouldn't depend on java2-runtime unless it worked with all of the uploaded ones, or at least the lowest-common-denominator, so that there was a reasonable expectation that it would work for the rest. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Help needed on the Java policy
On Sun, Jan 27, 2008 at 08:35:22PM +0100, Eric Lavarde wrote: > Hi, > > I'm fighting a bit with the current state of the Java policy, and it has > hit pretty hard because FreeMind isn't in testing anymore because of > this (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436206). > > OK, starting from the beginning: > 1. FreeMind 0.7.1 works only with Sun's Java (let's assume 1.4 only for > the sake of simplicity). > 2. i.e. I make my package depend on j2re1.4 | java2-runtime, the first > is necessary, the second is given by the policy. > 3. the issue is that anybody can then decide to fulfill the dependency > by installing whatever provides java2-runtime, even if I perfectly know > that it won't work. > > So, how can I fix this and respect the policy? > > Additional question: the Java RE packages created with java-package used > to depend on some X libraries, the sun-javaN-jre packages don't anymore. > What is the dependency one should best use for Java programs with an > (X-)Gui? Personally I would just depend on some working runtime and on java(2)-runtime and then forward all bugs specific to some runtime to the affected runtime. This help to gets the runtimes fixed. Otherwise they will never get fixed because people dont know the problems. In your case just depending on all the SUN JDK variants seems wrong. Do you know that the IBM variants dont work? How do you know that no (future) classpath-based runtime will work? What about icedtea? 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 Sun Jan 27 20:35, Eric Lavarde wrote: > Hi, > > I'm fighting a bit with the current state of the Java policy, and it has > hit pretty hard because FreeMind isn't in testing anymore because of this > (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436206). > > OK, starting from the beginning: > 1. FreeMind 0.7.1 works only with Sun's Java (let's assume 1.4 only for the > sake of simplicity). > 2. i.e. I make my package depend on j2re1.4 | java2-runtime, the first is > necessary, the second is given by the policy. > 3. the issue is that anybody can then decide to fulfill the dependency by > installing whatever provides java2-runtime, even if I perfectly know that > it won't work. AIUI, if it only works with Sun Java, you must depend on sun-java6-jre | sun-java5-jre, not the meta packages, since as you point out they could be fulfilled by non-sun packages. It will also have to go into contrib. If you wish to include packages from java-package, you need to include those in the or to, but being careful to explictly list sun packages, not something which will match other packages with which it will not work. Also note that since /etc/alternatives/java might point to something else, your wrapper script or other runtime support should explicitly use a working JRE. I would be tempted to insist on exactly one VM to depend on and use here. Matt -- Matthew Johnson signature.asc Description: Digital signature
Help needed on the Java policy
Hi, I'm fighting a bit with the current state of the Java policy, and it has hit pretty hard because FreeMind isn't in testing anymore because of this (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436206). OK, starting from the beginning: 1. FreeMind 0.7.1 works only with Sun's Java (let's assume 1.4 only for the sake of simplicity). 2. i.e. I make my package depend on j2re1.4 | java2-runtime, the first is necessary, the second is given by the policy. 3. the issue is that anybody can then decide to fulfill the dependency by installing whatever provides java2-runtime, even if I perfectly know that it won't work. So, how can I fix this and respect the policy? Additional question: the Java RE packages created with java-package used to depend on some X libraries, the sun-javaN-jre packages don't anymore. What is the dependency one should best use for Java programs with an (X-)Gui? Thanks, Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
