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