El dom, 05-04-2015 a las 17:16 +0100, James Le Cuirot escribió:
> 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. :(
>
Wouldn't be possible to show a repoman warning when a dependency on any
dev-java/${PN} doesn't specify a SLOT? That would save of from
forgetting this in some years ;)
