| Summary: | Java issues / cleanup with openoffice-2.0.4_rc1-r1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Josh Nichols (RETIRED) <nichoj> |
| Component: | New packages | Assignee: | Gentoo Office Team <office> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | java, jon |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Correcting bad java deps.
patch for current ebuild |
||
java-pkg-opt-2 also adds java to IUSE for you automatically. It looks like openoffice bundles sources for java libraries it uses... that's one issue, but trying to fix that is a bit beyond the scope of this bug. A problem because of this, though, is that one library, hsqldb, doesn't build with Java 1.6 (which we are testing with prerelease snapshots). To get around the issue, we need to use only 1.4 or 1.5, so the depends become: || ( =virtual/jdk-1.4* =virtual/jdk-1.5*) and rdepends: || ( =virtual/jre-1.4* =virtual/jdk-1.5*) (In reply to comment #0) > In DEPEND, ${JAVA_PKG_E_DEPEND} is considered internal. java-pkg-opt-2 RDEPENDs > and DEPENDs on this already for you. ok, removed that > sparc, iirc, is no longer supporting java in any of their profile, ie use.mask, > so the warning probably isn't necessary. also removed the warning > The conditional for checking javaness in src_unpack is a little icky. It would > be cleaner to use if statements instead of the use foo && something || > something, ie: > if use java; then > echo "--with-jdk-home=${JAVA_HOME} --with-ant-home=${ANT_HOME}" >> > ${CONFFILE} > else > echo "--without-java" >> ${CONFFILE} > fi Don't quite see what changing that gives us, that's basically the same, so I consider this a matter of personal taste. Or do I miss something problematic in the way it is done now? > java-pkg-opt-2 also adds java to IUSE for you automatically. right, removed java from IUSE > || ( =virtual/jdk-1.4* =virtual/jdk-1.5*) > and rdepends: > || ( =virtual/jre-1.4* =virtual/jdk-1.5*) fixed that too. Thanks a lot! (In reply to comment #2) > > || ( =virtual/jdk-1.4* =virtual/jdk-1.5*) > and rdepends: > || ( =virtual/jre-1.4* =virtual/jdk-1.5*) > Just recognized that this has an "interesting" side-effect: If I use the old dependencies, OOo chooses the 1.5-java and if I use your one it chooses 1.4-java. Was it by intent that you used =virtual/jdk-1.5* for RDEPEND? Cause if I change that to =virtual/jre-1.5* it works again. (In reply to comment #4) > Just recognized that this has an "interesting" side-effect: If I use the old > dependencies, OOo chooses the 1.5-java and if I use your one it chooses > 1.4-java. Was it by intent that you used =virtual/jdk-1.5* for RDEPEND? Cause > if I change that to =virtual/jre-1.5* it works again. I believe that was a typo, should be jre in RDEPEND. (In reply to comment #5) > (In reply to comment #4) > > Just recognized that this has an "interesting" side-effect: If I use the old > > dependencies, OOo chooses the 1.5-java and if I use your one it chooses > > 1.4-java. Was it by intent that you used =virtual/jdk-1.5* for RDEPEND? Cause > > if I change that to =virtual/jre-1.5* it works again. > > I believe that was a typo, should be jre in RDEPEND. > ok, thanks, just wanted to make sure Created attachment 99584 [details, diff] Correcting bad java deps. (In reply to comment #0) > In DEPEND, ${JAVA_PKG_E_DEPEND} is considered internal. java-pkg-opt-2 > RDEPENDs and DEPENDs on this already for you. Well, sort of. java-pkg-opt-2.eclass will add it to the DEPEND variable. However, as written right now openoffice-2.0.4.ebuild will override the DEPEND variable without including the old vale of ${DEPEND}. Basicly, if you don't include ${JAVA_PKG_E_DEPEND} you'll have to add ${DEPEND} to the dependency list instead. It would also be nice if someone fixed the jre/jdk mixup that has been present in three ebuild versions now. We need a jdk to build, but runtime a jre will suffice, so RDEPEND should contain "java? ( || ( =virtual/jre-1.5* =virtual/jre-1.4* ) )" and DEPEND should contain "java? ( || ( =virtual/jdk-1.4* =virtual/jdk-1.5* ) dev-java/ant-core )". (The order of 1.4 and 1.5 only changes the default, but I'd prefer if that was same as upstream, thus building with 1.4 but running with 1.5). The attached patch should clean this up. (In reply to comment #7) > The attached patch should clean this up. Thanks for pointing that out, I've fixed this now (In reply to comment #7) > Well, sort of. java-pkg-opt-2.eclass will add it to the DEPEND variable. > However, as written right now openoffice-2.0.4.ebuild will override the DEPEND > variable without including the old vale of ${DEPEND}. Basicly, if you don't > include ${JAVA_PKG_E_DEPEND} you'll have to add ${DEPEND} to the dependency > list instead. No, thanks not how it works, ebuild doesn't override (R)DEPENDs set in eclasses, it adds to them, you don't need to do what you propose. > It would also be nice if someone fixed the jre/jdk mixup that has been present > in three ebuild versions now. We need a jdk to build, but runtime a jre will > suffice, so RDEPEND should contain "java? ( || ( =virtual/jre-1.5* > =virtual/jre-1.4* ) )" and DEPEND should contain "java? ( || ( > =virtual/jdk-1.4* =virtual/jdk-1.5* ) dev-java/ant-core )". I agree, it's wrong that RDEPEND sets JDK and DEPEND sets JRE, should be the other way around. Also, JREs should ideally be only in RDEPEND, but now whole RDEPEND is included in DEPEND. Created attachment 99597 [details, diff]
patch for current ebuild
@Caster: The patch is not against latest cvs. Also could you please point out, why you introduce COMMON_DEPEND and maybe point me to a Gentoo reference where this is written down as a correct way to do? Never seen this before, so just trying to make sure... (In reply to comment #11) > Also could you please point out, > why you introduce COMMON_DEPEND and maybe point me to a Gentoo reference where > this is written down as a correct way to do? Never seen this before, so just > trying to make sure... Ok, forget this part, that's the sort of tunnel-view you get when only maintaing a few specific packages, sorry. (In reply to comment #11) > @Caster: The patch is not against latest cvs. Weird, it works here. > Also could you please point out, > why you introduce COMMON_DEPEND and maybe point me to a Gentoo reference where > this is written down as a correct way to do? Never seen this before, so just > trying to make sure... Well, for stuff that you need in both RDEPEND and DEPEND, it's best to put it in some variable first, and then expand that variable when definind RDEPEND and DEPEND. There's no policy of how the intermediate variable should be named, AFAIK... in Java ebuilds we usually use COMMON_DEPEND. Because the current way you first define RDEPEND and then expand it in DEPEND, you bring JRE deps into DEPEND where they are not really needed, you already have a JDK for building there. (In reply to comment #13) > > Weird, it works here. > Already commited the RDEPEND / DEPEND jre/jdk-exchange, maybe just didn't propagate... > > Well, for stuff that you need in both RDEPEND and DEPEND, it's best to put it > in some variable first, and then expand that variable when definind RDEPEND and > DEPEND. There's no policy of how the intermediate variable should be named, > AFAIK... in Java ebuilds we usually use COMMON_DEPEND. Because the current way > you first define RDEPEND and then expand it in DEPEND, you bring JRE deps into > DEPEND where they are not really needed, you already have a JDK for building > there. > Ok, so I'll follow that then. Just commited the fix, so I think we can close this again. (In reply to comment #9) > (In reply to comment #7) > > Well, sort of. java-pkg-opt-2.eclass will add it to the DEPEND variable. > > However, as written right now openoffice-2.0.4.ebuild will override the > > DEPEND variable without including the old vale of ${DEPEND}. Basicly, if > > you don't include ${JAVA_PKG_E_DEPEND} you'll have to add ${DEPEND} to the > > dependency list instead. > > No, thanks not how it works, ebuild doesn't override (R)DEPENDs set in > eclasses, it adds to them, you don't need to do what you propose. Since what portage version? I know that , once uppon a time, I read in Gentoo Developer Handbook that it was required, but it obviously isn't there any longer. So supposedly this is a relatively new feature. If any portage version >=2.0.51.22 (the version forced by the profiles) requires 'DEPEND="${DEPEND}...' to include the dependancies of eclasses I think the openoffice ebuild should include it. The eclass dependancy of >=sys-apps/portage-2.1_pre1 is quite worthes if you will circumvent it with an old enough portage... Also note that by grepping I found ~300 ebuilds containing 'DEPEND="${DEPEND} ...', and most of them hadn't multiple DEPEND defenition in the ebuild, so they must be doing it for the depends in their eclasses. I'm not saying they are correct and you are wrong, but I suspect there is a reason for it... (In reply to comment #15) > Since what portage version? > I know that , once uppon a time, I read in Gentoo Developer Handbook that it > was required, but it obviously isn't there any longer. So supposedly this is a > relatively new feature. I don't know if it was different in the past, but portage's been adding eclass deps to ebuild deps automatically since I've started writing ebuilds (i.e. this year). > If any portage version >=2.0.51.22 (the version forced > by the profiles) requires 'DEPEND="${DEPEND}...' to include the dependancies of > eclasses I think the openoffice ebuild should include it. I think all supported portage versions now do it automatically, otherwise Gentoo Developer Handbook would tell you to take care. > The eclass > dependancy of >=sys-apps/portage-2.1_pre1 is quite worthes if you will > circumvent it with an old enough portage... The dependency for >=sys-apps/portage-2.1_pre1 is there for phase hooks, not for this dependency adding. > Also note that by grepping I found ~300 ebuilds containing 'DEPEND="${DEPEND} > ...', and most of them hadn't multiple DEPEND defenition in the ebuild, so they > must be doing it for the depends in their eclasses. I'm not saying they are > correct and you are wrong, but I suspect there is a reason for it... Tried that grepping, some were plain typos where it should be DEPEND="${RDEPEND}, some were using DEPEND for common deps and then using it in both RDEPEND and DEPEND... And yes, there were some that would make it seems it's for including eclass deps. Maybe it's a mistake too, or they come from the times when this was not automatic. |
In DEPEND, ${JAVA_PKG_E_DEPEND} is considered internal. java-pkg-opt-2 RDEPENDs and DEPENDs on this already for you. sparc, iirc, is no longer supporting java in any of their profile, ie use.mask, so the warning probably isn't necessary. The conditional for checking javaness in src_unpack is a little icky. It would be cleaner to use if statements instead of the use foo && something || something, ie: if use java; then echo "--with-jdk-home=${JAVA_HOME} --with-ant-home=${ANT_HOME}" >> ${CONFFILE} else echo "--without-java" >> ${CONFFILE} fi