Hello all,

Firstly, I would like to take this opportunity to remind all devs
touching ebuilds with Java .jar dependencies about the importance of
restricting these dependencies to specific SLOTs.

There is no cross-platform or even platform-specific location for
Java .jar files so each distro tends to do its own thing. Gentoo's Java
eclasses install metadata about any .jar files in a file called
package.env either at /usr/share/${PN}-${SLOT} or just /usr/share/${PN}
when the SLOT is 0.

java-config is executed both at build time and at run time to read this
metadata so that it can build a classpath. If one of the dependencies
unexpectedly changes SLOT due to package updates then the chain breaks.
You must therefore *always* restrict the SLOT, even if that dependency
currently has a SLOT of 0.

Why do we SLOT Java stuff so much? Java applications tend to have many
third party dependencies so it is inevitable that we would sometimes
need to have more than one version of a library installed at one time.
The write once, run anywhere nature of Java also means that upstream
doesn't expect you to run against library versions other than the ones
they shipped their application with. We do have a tool to check for
compatibility between versions though to avoid SLOT proliferation
getting out of hand. Classpath conflicts involving multiple versions
have rarely been an issue up till now but we have thought of measures
to combat this in future if needs be.

I felt the need to write the above because I have seen many instances
where devs not familiar with Java packaging have made this mistake. Now
I need to ask what to do in the case of ebuilds that have already been
marked stable.

To bring up a real example, I would like to bump dev-java/jna with a
new SLOT for the new version. There are several reverse dependencies, 3
of which do not specify a SLOT, and 2 of these have already been marked
stable. Upon giving jna a new SLOT, all these packages would instantly
fail to build if jna:0 is not already installed and they would also
fail to run if jna:0 gets depcleaned. Simply leaving the stable ebuilds
as they are is therefore not an option. My preferred solution would be
create a revbump that solely amends (R)DEPEND, leaving the KEYWORDS
exactly as they are. This is controversial but what other choice is
there? I could delay the jna bump but this would push back this thread
of work by a month when I already have a huge backlog. Please do not let
bureaucracy get in the way here.

Of course I would certainly give any maintainers a heads up before
doing this. Unfortunately, in this particular case, I contacted miknix
about dev-embedded/arduino over 2 weeks ago and haven't heard anything
back. He hasn't been seen on IRC for over 5 months. :(

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer