Bug 164916 - Include full package-list for javadoc crosslinking
Summary: Include full package-list for javadoc crosslinking
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: jpackage-utils
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Thomas Fitzsimmons
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-02 16:53 UTC by Ville Skyttä
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version: 1.4.2.0-40jpp_78rh
Clone Of:
Environment:
Last Closed: 2006-02-08 21:22:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Include full package-list (1.51 KB, patch)
2005-08-02 16:53 UTC, Ville Skyttä
no flags Details | Diff

Description Ville Skyttä 2005-08-02 16:53:25 UTC
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.

Comment 1 Ville Skyttä 2005-08-02 16:53:25 UTC
Created attachment 117367 [details]
Include full package-list

Comment 2 Ville Skyttä 2005-09-22 20:18:56 UTC
Any comments about this patch? 

Comment 3 Thomas Fitzsimmons 2005-09-22 20:25:09 UTC
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?


Comment 4 Ville Skyttä 2005-09-22 20:41:22 UTC
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). 

Comment 5 Ville Skyttä 2006-01-18 22:21:59 UTC
Any progress on this?

Comment 6 Thomas Fitzsimmons 2006-01-26 14:14:25 UTC
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?


Comment 7 Ville Skyttä 2006-01-26 16:57:00 UTC
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.

Comment 8 Thomas Fitzsimmons 2006-02-03 23:21:00 UTC
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.


Comment 9 Thomas Fitzsimmons 2006-02-07 01:12:03 UTC
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.


Comment 10 Ville Skyttä 2006-02-08 17:01:09 UTC
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 ;)

Comment 11 Thomas Fitzsimmons 2006-02-08 17:09:09 UTC
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.


Comment 12 Ville Skyttä 2006-02-08 17:20:11 UTC
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...

Comment 13 Thomas Fitzsimmons 2006-02-08 20:15:45 UTC
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.


Comment 14 Thomas Fitzsimmons 2006-02-08 21:22:24 UTC
java-1.4.2-gcj-compat-1.4.2.0-40jpp_78rh is now in Rawhide.  Closing.



Note You need to log in before you can comment on or make changes to this bug.