1 |
Hi There! |
2 |
|
3 |
I'm neither dev, nor did I have the time to look at all the affected |
4 |
sources, so please be indulgent when I write nonsense. |
5 |
|
6 |
After some late night IRC chat with axxo, I have another plan to |
7 |
propose. I hope it might provide a way to smoothly change over, without |
8 |
having to break major functionality in between, and with the possibility |
9 |
to test things on ~arch first and to have changes on a per ebuild basis. |
10 |
|
11 |
|
12 |
Phase 1) |
13 |
|
14 |
The basic idea is to install wrappers in /usr/lib/java-wrappers or |
15 |
something like that for some time. So no current ebuilds would break. |
16 |
|
17 |
The location of java is determined by |
18 |
1. PATH, |
19 |
2. JAVA_HOME, |
20 |
3. java-config output or |
21 |
4. well known location (/usr/bin/). |
22 |
|
23 |
1. and 2. are environment settings and can be modified by an eclass |
24 |
(java-migrate.eclass?) so that new ebuilds could start using the new |
25 |
run-java-tool wrappers. |
26 |
For 3., those packages could depend on the new java-config. |
27 |
4. is a problem in any case, so that new ebuilds can be expected to have |
28 |
this solved or they won't work in any scenario. |
29 |
|
30 |
I give some details on the compatibility of java-config below. |
31 |
The idea is to have java-config handle new style symlinks and old style |
32 |
env setting files at the same time with almost no work to be done. |
33 |
|
34 |
|
35 |
Phase 2) |
36 |
|
37 |
Now the wrappers are available, and ebuilds can at merge time switch to |
38 |
using them instead of the old style VM settings. New ebuilds would use |
39 |
an eclass to set the environment accordingly and to DEPEND on a recent |
40 |
java-config. This could be done on a per ebuild basis, first for ~arch |
41 |
and then for arch. |
42 |
|
43 |
Packages that need it could DEPEND on javatoolkit as well. |
44 |
New eclasses can be provided as long as they set correct DEPENDencies. |
45 |
|
46 |
|
47 |
Phase 3) |
48 |
|
49 |
All "complicated" ebuilds should be moved to using the new system. Those |
50 |
are the ones that don't simply call ant but do some more elaborate |
51 |
stuff. By a new version of java-config, the 20java file could be changed |
52 |
again to make /usr/lib/java-wrappers the JAVA_HOME. Details for this are |
53 |
below again. ant should continue to work, so still nothing breaks. |
54 |
Now the new style is the default, and the old style is adapted to use |
55 |
the new wrappers. |
56 |
|
57 |
Phase 4) |
58 |
|
59 |
java 1.5 can be unmasked for ~arch. Things that still don't work will be |
60 |
noticed and can be fixed by using the merge time features of the new |
61 |
system without much trouble. |
62 |
|
63 |
Phase 5) |
64 |
|
65 |
All ebuilds should be changed to using the wrappers and stabilized. |
66 |
Now the wrappers could be symlinked, copied or moved to /usr/bin, the |
67 |
env setting file 20java could be enoticed for removal. |
68 |
|
69 |
|
70 |
|
71 |
Details on compatibility of java-config and run-java-tool: |
72 |
|
73 |
Using the run-java-tool wrappers with java-config would require a recent |
74 |
version of java-config. I suggest the java-config ebuild makes |
75 |
/etc/env.d/20java a symlink to /etc/java-config/system-vm/env-settings |
76 |
or some such, and every jdk and jde contains this settings file (which |
77 |
is just a copy / symlink to the file listed in /etc/env.d/java if I got |
78 |
this right). This can be done with the revision bumps that are needed |
79 |
anyway. |
80 |
|
81 |
So as the new java-config changes the system-vm symlink, automatically |
82 |
the contents of 20java changes, and the usual procedure of env-update |
83 |
and source profile makes this configuration change active, as it was |
84 |
with java-config so far. The new java-config would without much |
85 |
additional work reproduce the workings of the old one, in addition to |
86 |
changing the symlinks in the new style. |
87 |
|
88 |
The 20java file as it was when installing could be moved to some new dir |
89 |
(e.g. /etc/java-config/old-vm), and the java tools identified by the |
90 |
java file could be symlinked to this directory as well, so that this |
91 |
directory can be used as a new style java vm installation exactly |
92 |
representing the settings in effect when the java-config ebuild is |
93 |
installed. When java-config is called to switch vm, the system-vm |
94 |
symlink changes and the directory just described may be safely removed. |
95 |
|
96 |
So to sum it up, here is how java-config installation should work: |
97 |
1. mkdir -p /etc/java-config/old-vm/bin |
98 |
2. mv /etc/env.d/20java /etc/java-config/old-vm/env-settings |
99 |
3. ln -s ../java-config/system-vm/env-settings /etc/env.d/20java |
100 |
4. ln -s old-vm /etc/java-config/system-vm |
101 |
5. ln -s `java-config -c` /usr/java-config/old-vm/bin |
102 |
same for all the other java tools |
103 |
|
104 |
3. makes sure that vm changes with the new java-config also change the |
105 |
environment settings the way the old config did. |
106 |
2. makes the current settings available for old style env-update. |
107 |
5. makes the currently selected vm available for the new style wrappers, |
108 |
it would have to use the old java-config. |
109 |
4. sets this constructed configuration as current vm in the new style. |
110 |
|
111 |
The user would need new VM packages with new environment setting files |
112 |
only for switching VM, the current setting would continue to work under |
113 |
the new java-config even without this update. |
114 |
|
115 |
|
116 |
|
117 |
Details about the flow of indirection in Phase 3) |
118 |
|
119 |
Before Phase 3 we had for old ebuilds: |
120 |
1. env-update reads 20java |
121 |
2. 20java points into system-vm |
122 |
3. system-vm is set by java-config to point to jdk |
123 |
4. jdk provides env settings |
124 |
5. env settings provide access to java, javac and so on |
125 |
|
126 |
Now we have for the same old ebuilds: |
127 |
1. env-update reads 20java |
128 |
2. 20java sets env settings |
129 |
3. env settings provide access to wrappers |
130 |
4. wrappers use system-vm |
131 |
5. system-vm set by java-config |
132 |
|
133 |
|
134 |
Greetings, |
135 |
Martin von Gagern |