Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >The definition of what's to be expected as normal keeps changing all the
> time
> >in the java world, as I'm trying to make clear with my questions on your
> >interpretation of java's class loading semantics.
>
> >From your point, but not from the guy starting a java app...
You're using a straw man argument here. Things really keep changing all the
time *and* it matters, even for the normal guy starting a java app.
Look here for example at the apache ant announcement for ant 1.5.4 (latest ant)
here http://marc.theaimsgroup.com/?l=apache-announce&m=106077068513961&w=2 .
They had to fix the javah task because sun changed something about their
internal classes in java 1.4.2.
So what's your normal ant-running guy to do in this case? Moan about Sun
changing internals of their implementation and demand that the debian
maintainer reverts the change so that ant 1.5.3 from testing still works?
> >> Yes, but does kaffe1.1.1 replace sablevm? Or a BD java 1.3?
> >Why should it?
>
> You should have a look at the alternative system on debian maschines.
>
> Currently /usr/bin/java is managed via this alternative system. So the
> package, which supplys the highes priority wins and gets
> '/usr/bin/java'. If sablevm and kaffe are installed and I depend on
> kaffe, but sablevm installs a higher priority, then I'm f****d up.
I think we both agree that this scheme is not a good solution for java on
debian. It doesn't give users the necessary flexibilty to deal with ever
changing definition of what should be considered as normal in java. For example
I can't really make sure that I run ant 1.5.3 with Sun's JDK 1.4.1 because I
need the javah task to work, but nevertheless want to run other apps with JDK
1.4.2 as far as I understand the priority game.
> >I'd consider kaffe removing some other unrelated package from my
> >system to be a serious bug.
>
> It has nothing to do with the packaging system, but with alternatives.
> man update-alternatives
update-alternatives is useless for non-root users. See for example this
session:
[see if update/alternaitves is installed and its synopsis]
bash-2.05a$ update-alternatives
update-alternatives: need --display, --config, --install, --remove or --auto
Debian update-alternatives 1.9.21.
Copyright (C) 1995 Ian Jackson.
Copyright (C) 2000,2001,2002 Wichert Akkerman
This is free software; see the GNU General Public Licence
version 2 or later for copying conditions. There is NO warranty.
Usage: update-alternatives --install <link> <name> <path> <priority>
[--slave <link> <name> <path>] ...
update-alternatives --remove <name> <path>
update-alternatives --auto <name>
update-alternatives --display <name>
update-alternatives --config <name>
<name> is the name in /etc/alternatives.
<path> is the name referred to.
<link> is the link pointing to /etc/alternatives/<name>.
<priority> is an integer; options with higher numbers are chosen.
Options: --verbose|--quiet --test --help --version
--altdir <directory> --admindir <directory>
[display alternatives for java]
bash-2.05a$ update-alternatives --display java
java - status is auto.
link currently points to /usr/lib/j2se/1.3/bin/java
/usr/lib/jdk1.1/bin/java - priority 111
slave java.1.gz: /usr/share/man/man1/java-jdk11.1.gz
/usr/lib/kaffe/bin/java - priority 300
slave java.1.gz: /usr/share/man/man1/kaffe.1.gz
/usr/bin/gij-wrapper-3.2 - priority 32
slave java.1.gz: /usr/share/man/man1/gij-wrapper-3.2.1.gz
/usr/lib/j2se/1.3/bin/java - priority 1311
slave java.1.gz: /usr/share/man/man1/java.j2se13.1.gz
Current `best' version is /usr/lib/j2se/1.3/bin/java.
[i prefer free software, so let's pick kaffe]
bash-2.05a$ update-alternatives --config java
There are 4 programs which provide `java'.
Selection Command
-----------------------------------------------
1 /usr/lib/jdk1.1/bin/java
2 /usr/lib/kaffe/bin/java
3 /usr/bin/gij-wrapper-3.2
*+ 4 /usr/lib/j2se/1.3/bin/java
Enter to keep the default[*], or type selection number: 2
Using `/usr/lib/kaffe/bin/java' to provide `java'.
update-alternatives: unable to make /etc/alternatives/java.dpkg-tmp a symlink
to /usr/lib/kaffe/bin/java: Permission denied
hooray for update-alternatives being helpful ;)
> >> Lets say it this way: There is such a thing as a reasonable debian
> >> developer and I think that he should be able to sort that out.
> >Unfortunately, I still don't get it. Do you expect VM maintainers to
> >rate the compliance of their VM packages, some third party (like
> >yourself), or the users after they install a VM?
>
> Actually I don't mind at all, what the free VM package use as a
> priority. What I mind are the unfree ones for teh alternatives of
> /usr/bin/java-version.
Then the bit about specifying priorities with a bonus for free VMs should go
away. I guess you can kill the rest of the priority scheme along with it, as
according to your notion of compatibility (which seems to be it's labelled
Java(TM) so it's compatible) they are all equally compatible and so on.
> If this is such aproblem, then I will change my proposal to only
> specify the unfree interface priorities (basicly: release x 100).
Stupid question: what's a release? What priority value should be given to J2SE
v 1.4.2_01 ? 142? 142.01? 14201?
> >I wouldn't let the packager decide what VMs should be tried in which order,
> as
> >I want to be able to set my preferences myself (and I may not want to prefer
> >VMs based on their perceived compliance with JDK 1.4 APIs, for example),
> just
> >let the packager limit the options to the VMs that are known to work with
> the
> >package.
> [...]
>
> This could be done at a later time with a app, which will return a
> installed 'java' command (java as in 'runs java byte code), based on
> installed packages and known working packages and user preferences. If
> you want to supply such a app, it could go into java-common and policy
> could be changed, so that apps have to use it.
I think that such an app would help solve the current problems with picking the
'right' java executable for the job in a more general fashion than what we have
now (weird and useless /usr/bin/java interface with even weirder alternatives
scheme) or your proposal, which seems to try to band-aid debian to limp along
with the non-free VMs by introducing a non-free interface with another weird
rating system.
Of course, only if the underlying problem is to find the 'right' java
executable, which is how I parsed the discussion so far.
> I hope you understand, that I have already enought work with
> implementing my proposal, before I try another one :)
>
> >> I don't mind which package it finds first, but that it *only* finds JVM,
> >> which are capable of running the programm.
> >what about adding a /usr/share/java/jarregistry directory with a file per
> java
> >package that contains a
> >Debian-Can-Run-On-VM: vm-a vm-b
>
> This should be done at buildtime and not at runtime. Again, it may be
> done via the above described 'findjava' script.
I beg to disagree. I want to be able to change my preferences at runtime,
instead of having to rely on a packager to get it right when he packages the
application. I want the flexibilty to be able to work around bugs in non-free
VMs by picking a free one, even if the application in question worked better
for an old release of the non-free VM that the packager tested it with.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: