... address the same problems, I realize that I did not do very much research to prior proposals and discussion on the matter, for which I aplogize. I didn't want to delay this mail until I'd find time to do such research, and this idea wasn't as 'current' anymore. --Jeroen -- Jeroen van Wolffelaar Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl

...> much research to prior proposals and discussion on the matter, for which I aplogize. I didn't want to delay this mail until I'd find time to do such research, and this idea wasn't as 'current' anymore. Your proposal only addresses runtime environments, not build dependencies, and how they should configured. We discussed that in Oldenburg (you included). You may want as well look at ...

...I didn't want to delay this mail until I'd find time to do such research, and this idea wasn't as 'current' anymore. so, in order to address the problems above: proposed solution to problem ...to Java. One way would be to extend update-alternatives with the concept of a "group hook"? The idea would be that modifying the alternative without using the group hook would result in a "are you ...

... of needing to marshal more than one alternative at the same time -- may not be limited to Java. One way would be to extend update-alternatives with the concept of a "group hook"? The idea would be that modifying the alternative without using the group hook would result in a "are you sure?" message. The problem with this solution is that it would require a fundamentally ...

... the introduction of a null-environment with dummy binaries would avoid that. That sounds like a good idea. Should we also add a comment to all JVM post-inst's that selecting this (or any) ...Java. One way would be to extend update-alternatives with the concept of a "group hook"? The idea would be that modifying the alternative without using the group hook would result in a "are you...

.../features/org.apache.commons_logging.feature_1.0.4.v200606152055--0842282-233879.jar.] It will happily discover the available features but if I try to install any I get message similar to the above. It happens whatever site or mirror I use. running deb testing eclipse Version: 3.1.2 Build id: M20060118-1600 (Debian version: 3.1.2-2) Any ideas to fix would be appeciated. AG

[Arnaud Vandyck] Any other thoughts? I believe this is a good idea. I have tried to get someone in the debian-edu community to write a press release announcing our support for this license change, but am not sure if anyone will pick up the ball. I believe it is important to get the press to write about how this change is received, to encourage other companies to do the same. Is ...

... it, that nobody honors my request for CC?] Thanks for the answers. I would definitely recommend to create a java5.0-compiler and java5.0-runtime package. I don't like the idea because the development environment is not just about a compiler; also, there are plans for java6 and java7: how many virtual package will we have in Debian? As Java should be compatible with old compiled ...

..., that nobody honors my request for CC?] Thanks for the answers. I would definitely recommend to create a java5.0-compiler and java5.0-runtime package. I don't like the idea because the development environment is not just about a compiler; also, there are plans for java6 and java7: how many virtual package will we have in Debian? As Java should be compatible with ...

... is still a lot of work for everything to be integrated; o Debian currently supports java compatible infrastructure on more archs than the sun jdk supports. I would like to pick up the ideas from the Oldenburg meeting last year for arch dependent packages default-jre and default-jdk. o We (Ola Ludvig and other?) are working to build hotspot and javac with free software...