[gentoo-dev] Importance of SLOTs on Java dependencies

[gentoo-dev] Importance of SLOTs on Java dependencies

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 2878 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

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

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> My preferred solution would be
> create a revbump that solely amends (R)DEPEND, leaving the KEYWORDS
> exactly as they are. 

Sounds good to me (as long as repoman agrees :).


- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVIWGTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5Ht4P/RBt9rbsNkOkR03dzddjwSqK
1VJCF+YhWUXDatY1dwVtPJQ8bfv1H3qW1WB7XfhtOZqZzCqiDq7irS9aog6YgYcz
NTWWZhYTG9PU9XV+CoFb+4jkVgHa8IuCrGfg0idNQd7QVktozJO7/LnJbu4PDzw3
exEHMuqVVj3iub0CZlBX0OJiii5G3k5CjuVw1GAKJ0j2Od55FtQnIMYJqJfJdZGj
7i0Aerr9glCwfhojxzcCy6hlJaMdSvlPPvZw/NCujETTZJbpM72TPzMs4xr7rXIJ
T0zoNzKe05Mkmitm+Hw7OkY4Acfh94tVK3FzEUv1ZqFW7prEBjOmh3vSqsjHsuWf
PQ0EApnIOI7bOIjJDwIbZaCtehr/727mDV4JLH/guFGD9+pvLHszGHDr5Ga+t/Mk
TVmIWkevGVfsUcaVfLF7d2LCoVA0Nup5Mdudsj8yZ7fwAIL0DfceBM+Wdf3V5kE1
Vg0JDGlU3JYyfLf9lcuhVZcueYWOGY6n4UMbajtrUWyjsterktCRtpKM/1zmc+i/
cgnzsdzJde5JsSjrEU4RrPvezZKhJ0+LtcyI4d310OjGlDkK6pwFEe7NE9z4HqxX
dBkhCsZDgVYAy6sT/LDD60Num2sC3BdBKNyk8gjIf5GoSFOLiINL/fmQQa87/pBM
IHa+KkSrQHOB+GhB0VKF
=tTas
-----END PGP SIGNATURE-----

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

[Pacho Ramos]

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 ;)

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 ;)
> 
> 

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

[James Le Cuirot]

On Wed, 8 Apr 2015 17:10:30 +0200
Patrice Clement <monsieurp@gentoo.org> wrote:

> Tuesday 07 Apr 2015 20:41:05, Pacho Ramos wrote :
> > 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 ;)
> > 
> Chewi suggested a similar solution in #gentoo-java. How do we get
> started with contributing to repoman?

The change I intend to make is not to repoman but java-utils-2.eclass
where there is already a check to ensure that a dependency has been
added, it just doesn't check the SLOT at the moment. It outputs an
error message by default but dies if you have JAVA_PKG_STRICT set,
which all Java devs should do.

P.S. Quit top posting. :P

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

On Wed, 8 Apr 2015 16:25:20 +0100
James Le Cuirot <chewi@gentoo.org> wrote:

> On Wed, 8 Apr 2015 17:10:30 +0200
> Patrice Clement <monsieurp@gentoo.org> wrote:
> 
> > Tuesday 07 Apr 2015 20:41:05, Pacho Ramos wrote :
> > > 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 ;)
> > > 
> > Chewi suggested a similar solution in #gentoo-java. How do we get
> > started with contributing to repoman?
> 
> The change I intend to make is not to repoman but java-utils-2.eclass
> where there is already a check to ensure that a dependency has been
> added, it just doesn't check the SLOT at the moment. It outputs an
> error message by default but dies if you have JAVA_PKG_STRICT set,
> which all Java devs should do.

I just got this warning and had to do some digging to figure out where it
came from and what it wanted me to do. Can you add a comment to the eclass
(maybe a link to your mail which explained things well) and a pointer to the
eclass in the message?


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 475 bytes --]

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On Sun, 19 Apr 2015 03:38:09 -0600
Ryan Hill <rhill@gentoo.org> wrote:

> On Wed, 8 Apr 2015 16:25:20 +0100
> James Le Cuirot <chewi@gentoo.org> wrote:
> 
> > On Wed, 8 Apr 2015 17:10:30 +0200
> > Patrice Clement <monsieurp@gentoo.org> wrote:
> > 
> > > Tuesday 07 Apr 2015 20:41:05, Pacho Ramos wrote :
> > > > 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 ;)
> > > > 
> > > Chewi suggested a similar solution in #gentoo-java. How do we get
> > > started with contributing to repoman?
> > 
> > The change I intend to make is not to repoman but
> > java-utils-2.eclass where there is already a check to ensure that a
> > dependency has been added, it just doesn't check the SLOT at the
> > moment. It outputs an error message by default but dies if you have
> > JAVA_PKG_STRICT set, which all Java devs should do.
> 
> I just got this warning and had to do some digging to figure out
> where it came from and what it wanted me to do. Can you add a comment
> to the eclass (maybe a link to your mail which explained things well)
> and a pointer to the eclass in the message?

Done! :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]