Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Importance of SLOTs on Java dependencies
Date: Tue, 07 Apr 2015 18:41:22
In Reply to: [gentoo-dev] Importance of SLOTs on Java dependencies by James Le Cuirot
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 >
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 ;)


Subject Author
Re: [gentoo-dev] Importance of SLOTs on Java dependencies Patrice Clement <monsieurp@g.o>