Re: [gentoo-dev] Importance of SLOTs on Java dependencies

[Patrice Clement]

Chewi suggested a similar solution in #gentoo-java. How do we get started with
contributing to repoman?

However.. everytime I tried asking questions about repoman, I've been told I
shouldn't bother improving it because this magic python script that seems to be
doing all sort of things (over 3000 lines packed in one file) (yes my dear) is
being rewritten.

Is it still underway?

Cheers

Tuesday 07 Apr 2015 20:41:05, Pacho Ramos wrote :
> 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 ;)
>
>