Red Hat Bugzilla – Bug 164916
Include full package-list for javadoc crosslinking
Last modified: 2007-11-30 17:11:11 EST
The FC version of jpackage-utils includes an empty package-list and provides java-javadoc which gives a false impression that at least crosslinked javadocs could be built sanely with it. The attached patch adds the full package-list file from GNU classpath, which makes javadoc crosslinking work as expected. Fix attached.
Created attachment 117367 [details] Include full package-list
Any comments about this patch?
Looks good; we're actually going to build and ship the GNU Classpath javadocs with FC5. How is package-list generated? We're hoping to build the class library javadocs from within the libgcj build process. Should this package-list file be generated as part of that process?
Yes, package-list should be generated as part of the javadoc build. That plan sounds good and provided that a full /usr/share/javadoc/java/package-list file will be shipped in FC5, I'm fine with closing this bug. OTOH the patch would be a trivial one for FC4... BTW, in case you're not aware of it, there's a "classpath-javadoc" package in JPackage; it'd be cool to take that into account in the FC5 one somehow (compatibility/obsoletion).
Any progress on this?
OK, I'd like to hack something together for FC5. Like I say, long-term I don't want gjdoc as a separate package, I want it merged into GNU Classpath (and so the libgcj RPM). Then we could generate package-list and the javadocs in the libgcj RPM build and symlink the results in java-gcj-compat. It was proposed to add gjdoc as a build requirement for libgcj but I'm against that in general (minimize circular dependencies) and I don't think it'll happen before FC5 anyway. So in the short term what's the best way of solving this for FC5? I can't just package classpath-javadoc obviously because they'll be different from the installed libraries (though I will add an Obsoletes + virtual provides for this). I think the best thing to do would probably be generate javadocs and package-list in java-gcj-compat by having a build requirement on libgcj-src. Does that sound workable to you?
Yep, I think that would work. On the other hand, if the longer term plan is to merge gjdoc to libgcj and generate the docs during that build, maybe generating them in the gjdoc rpm already now would be worth considering too.
Currently libgcj-src doesn't include all the class library documentation due to a bug in its build scripts. I've submitted a fix upstream.
The libgcj-src bug is now fixed and I've built java-1.4.2-gcj-compat-1.4.2.0-40jpp_76rh into Rawhide. It contains a new subpackage, java-1.4.2-gcj-compat-javadoc which installs gjdoc-generated class library documentation, including a full package-list, in /usr/share/javadoc/java. Closing.
Thanks, looks good. A FYI though: this new javadoc package won't play well with the way JPackage's javadoc packages are installed; they install into fully versioned dirs below /usr/share/javadoc and symlink themselves as /usr/share/javadoc/java in their %post scriptlets, for example http://www.zarb.org/cgi-bin/cvsweb.cgi/rpms/non-free/java-1.4.2-sun-manual/java-1.4.2-sun-manual.spec?rev=1.2;cvsroot=jpackage;only_with_tag=JPACKAGE-1_7 This package will obviously break that because /usr/share/javadoc/java is not a symlink. But as said, just a FYI, I don't personally mind that much ;)
Thanks for the pointer. I looked for that package on jpackage.org but missed it because I was looking for "javadoc" not "manual". I'll adapt java-1.4.2-gcj-compat-javadoc to be compatible with this package.
Actually, this is probably the most up-to-date -javadoc package in JPackage: http://www.zarb.org/cgi-bin/cvsweb.cgi/rpms/free/classpath/Attic/classpath.spec?rev=1.1.2.2;content-type=text%2Fx-cvsweb-markup;cvsroot=jpackage;hideattic=0;only_with_tag=JPACKAGE-1_6 ...and I'm not completely sure, but I think that if you implement the %post symlinking in this java-1.4.2-gcj-javadoc package, upgrading from the current version will fail (because the files from the previous package will still be present at %post-of-new-package time). But considering that this is a new package and we're talking Rawhide, maybe that's acceptable...
There will be breakage updating from 1.4.2.0-40jpp_7{4,5,6,7}rh to >= 1.4.2.0-40jpp_78rh but that's fine between two Rawhide versions. The workaround is to run: rm -rf /usr/share/javadoc/java before updating java-1.4.2-gcj-compat. I'm building the new package into Rawhide now.
java-1.4.2-gcj-compat-1.4.2.0-40jpp_78rh is now in Rawhide. Closing.