1 |
Hello all, |
2 |
|
3 |
Firstly, I would like to take this opportunity to remind all devs |
4 |
touching ebuilds with Java .jar dependencies about the importance of |
5 |
restricting these dependencies to specific SLOTs. |
6 |
|
7 |
There is no cross-platform or even platform-specific location for |
8 |
Java .jar files so each distro tends to do its own thing. Gentoo's Java |
9 |
eclasses install metadata about any .jar files in a file called |
10 |
package.env either at /usr/share/${PN}-${SLOT} or just /usr/share/${PN} |
11 |
when the SLOT is 0. |
12 |
|
13 |
java-config is executed both at build time and at run time to read this |
14 |
metadata so that it can build a classpath. If one of the dependencies |
15 |
unexpectedly changes SLOT due to package updates then the chain breaks. |
16 |
You must therefore *always* restrict the SLOT, even if that dependency |
17 |
currently has a SLOT of 0. |
18 |
|
19 |
Why do we SLOT Java stuff so much? Java applications tend to have many |
20 |
third party dependencies so it is inevitable that we would sometimes |
21 |
need to have more than one version of a library installed at one time. |
22 |
The write once, run anywhere nature of Java also means that upstream |
23 |
doesn't expect you to run against library versions other than the ones |
24 |
they shipped their application with. We do have a tool to check for |
25 |
compatibility between versions though to avoid SLOT proliferation |
26 |
getting out of hand. Classpath conflicts involving multiple versions |
27 |
have rarely been an issue up till now but we have thought of measures |
28 |
to combat this in future if needs be. |
29 |
|
30 |
I felt the need to write the above because I have seen many instances |
31 |
where devs not familiar with Java packaging have made this mistake. Now |
32 |
I need to ask what to do in the case of ebuilds that have already been |
33 |
marked stable. |
34 |
|
35 |
To bring up a real example, I would like to bump dev-java/jna with a |
36 |
new SLOT for the new version. There are several reverse dependencies, 3 |
37 |
of which do not specify a SLOT, and 2 of these have already been marked |
38 |
stable. Upon giving jna a new SLOT, all these packages would instantly |
39 |
fail to build if jna:0 is not already installed and they would also |
40 |
fail to run if jna:0 gets depcleaned. Simply leaving the stable ebuilds |
41 |
as they are is therefore not an option. My preferred solution would be |
42 |
create a revbump that solely amends (R)DEPEND, leaving the KEYWORDS |
43 |
exactly as they are. This is controversial but what other choice is |
44 |
there? I could delay the jna bump but this would push back this thread |
45 |
of work by a month when I already have a huge backlog. Please do not let |
46 |
bureaucracy get in the way here. |
47 |
|
48 |
Of course I would certainly give any maintainers a heads up before |
49 |
doing this. Unfortunately, in this particular case, I contacted miknix |
50 |
about dev-embedded/arduino over 2 weeks ago and haven't heard anything |
51 |
back. He hasn't been seen on IRC for over 5 months. :( |
52 |
|
53 |
-- |
54 |
James Le Cuirot (chewi) |
55 |
Gentoo Linux Developer |