Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> [kdelibs4 problems]
> >> all cases to '1', but the latest qt version in unstable is '2'. I don't
> >> think that anyone bothers to test their packages, when one of the
> >> dependencies changed.
> >Whoever changed the dependency should have tested the packages that depend
> on
> >it, in my opinion.
>
> Noone changed anything. The only change was, that there is now a new
> qt lib in unstable, which wasn't there during the last build of
> kdelibs4.
>
> Should the qt maintainer compile every kde app when he uploaded a new
> version? The kde maintainer, when any of his dependencies has changed?
In my opinion, the debian build deamon should get a twin quality assurance
deamon brother that should try to build the depending packages with the
successfully built new version, and run their regression tests (make check).
Then the maintainer should be notified about the problems, and he couild decide
whether to revoke the package, or to let it pass and fix the problems later.
Let the machines do what they are best at: monotonous tasks like this ;)
> >> What I say is, that you can assume, that if you compile your java
> >> package to java byte code (version ...), then a 'sun derived' VM will
> >> run it. I consider that save enough and a lot of better than the
> >> current practise.
> >There are examples available that clearly show that this assumption is not
> >valid.
>
> May I hear them?
The ant javah exaple from the last mail shows that any application that depends
on the unpublished, undocumented internals of sun's implementation is bound to
fail on another version of a sun derived VM than the one it was developed with.
Here's some more documentation on documented binary and source
incompatibilities between different releases of Sun derived VMs:
http://java.sun.com/j2se/1.4.2/compatibility.html
Please note that the incompatibilities between minor releases are actually
summed up between differnt point-releases, where they used to exist just like
with 1.4. So all the differences between 1.3.0 and 1.3.1 are actually meshed
together in the web pages.
Sun never documents their changes in their internal classes, so all apps
depeding on it are, and will be broken by upgrades. Sun's licensees, like IBM
and BD, can also make undocumented changes to those classes.
Convinced?
> >> So you find it acceptable, if one has 5 java packages, which need 5
> >> different JVM, *althought* one of this JVM will run all 5 packages?
> >Of course.
>
> Then you have missed the point with java...
You're blaming me for trying to cure other people's mistakes here.
It's the developers who use undocumented features of Sun's implementation (like
JAVA_HOME, sun.* classes and so on) that miss the point with java: they tie
their code to one particular instance of a non-free JVM. If their code runs at
all on another release of a non-free VM, then it does so by pure luck.
I propose to explicitely state which VMs are known to run the code, since I
don't want to assume anything about untested VMs. You assume that other VMs
derived from the same code base will continue to run the code. I don't think
that's a valid assumption to make, given a) the amount of non-portable java
code out there, and b) binary incompatibilities between point-releases in Sun's
own VMs.
> >I may want to run one package on one VM, the other one on another,
> >because it performs better on it, for example. What's wrong with picking the
> >right tool for the job? What's wrong with having a choice?
>
> Nothing is wrong with that. I'm only wondering, why you want to
> prevent that the users has this choice... If I have the knowledge what
> JVM works best with my app, then I will also have no problem with
> downlaoding this packages, *if* I need them. In all other cases, I
> think that 'it is able to run it' will be enough.
I think I wasn't clear enough, I'm sorry about that. I don't want to prevent
users to have a choice, as I'm a user myself, and I showed in my
update-alternatives example that I want to have some flexibililty myself, that
current debian java support doesn't offer me.
You seem to fail to realize that we are arguing pro very similar things: I say
list all the VMs that the maintainer knows will run the package in the
dependencies, and give the user some means to pick whatever he needs, but make
sure that he has a one of the possible very many supported VM installed to run
his program on. So for my cool HelloWorld application debian package, I'd list
all VMs in debian after testing they can run my HelloWorld app.
You also propose that the maintainer must use an abbreviation for a subset of
non-free VMs, and claim that the application runs with all of those VMs, even
if he can't verify such claims. I think that's wrong. I don't want to prevent
the maintainer from testing his apps on non-free VMs, and claiming they run on
them. It's their business if they want to agree to non-free licenses.
If a maintainer tests his package on BD, IBM and SUN's VM, why shouldn't he
include it in the dependency list? But if a maintainer only tests his package
on Sun's VM, then I think it's not honest to state that it also runs on IBM or
BD VM. ;)
So to sum it up, I don't want to prevent maintainers to claim that their
package runs with non-free VMs. They can test, and then they can claim. In
fact, a system that allows the user to override the choice made by the
maintainer would be great, and is what I propose with the findjava script.
> >Then it should be up to you to collaborate with the maintainers to make sure
> >their packages build on the single particular VM environment you decided to
> >pick for yourself and to aid them in providing support for it.
>
> No. If we have that, we could forget about java policy and just use
> the normal debian policy. I won't do that.
Where is the problem with helping the package maintainers do a better job and
support more VM environments out of the box, including whatever your favorite
one is? Isn't that how debian is supposed to work? People helping each other to
improve debian, and so on? Or did your attitude (you're after all trying to
make a useful java policy) change suddendly?
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: