Bug 167482

*** Bug 167481 has been marked as a duplicate of this bug. ***

Why did you import the package into CVS without anybody else reviewing your
package?  The rules exist for a reason and apply to everyone now.

http://fedoraproject.org/wiki/Extras/NewPackageProcess
Please review the Extras package process

Ok, my bad.  Sorry.  It's a bit confusing.  At first somebody told me to apply
for CVS access.  I was granted access yesterday, and then was pointed at

http://fedoraproject.org/wiki/Extras/Contributors

Which says post your first SRPM and then apply for access.  But I've already
been given access so I thought I could skip to step 11.

So, should I remove it now (although I don't know how)?  Or maybe somebody can
review it quickly?

Thanks.

You can remove the "Epoch: 0" from FC3+ packages, and also the "0:" in the
versioned dependency.  Epoch in versioned dependencies are needed in cases
however where the epoch is greater than zero.

%ghost %doc %{_javadocdir}/%{name}
What is the purpose of this?  This looks extremely odd.

I didn't test a build yet and I don't know java packaging too well, so hopefully
we can get more input from someone else.

+ cd make
+ ant -Duser.home=/home/builder/rpmbuild/SOURCES linux javadoc.dev.x11
/usr/bin/build-classpath: error: could not find jaxp_parser_impl Java extension
for this JVM
/usr/bin/build-classpath: error: All specified jars were not found
Buildfile: build.xml

I noticed this error when building other java things like bootchart.  It doesn't
seem to be fatal to the build process.  Do we have any package that contains
this, and what does it do, and why doesn't the build fail?  Should it become a
BuildRequires?

(In reply to comment #4)
> You can remove the "Epoch: 0" from FC3+ packages, and also the "0:" in the
> versioned dependency.  Epoch in versioned dependencies are needed in cases
> however where the epoch is greater than zero.

Ok.  I was just following the practice established in all of the FC java packges.

> %ghost %doc %{_javadocdir}/%{name}
> What is the purpose of this?  This looks extremely odd.

To be honest, I'm not sure.  It's just established practice for FC java packages.
 
> I didn't test a build yet and I don't know java packaging too well, so hopefully
> we can get more input from someone else.

I'll add fitzsim to CC.  I hope he doesn't mind :-)

(In reply to comment #5)
> + cd make
> + ant -Duser.home=/home/builder/rpmbuild/SOURCES linux javadoc.dev.x11
> /usr/bin/build-classpath: error: could not find jaxp_parser_impl Java extension
> for this JVM
> /usr/bin/build-classpath: error: All specified jars were not found
> Buildfile: build.xml
> 
> I noticed this error when building other java things like bootchart.  It doesn't
> seem to be fatal to the build process.  Do we have any package that contains
> this, and what does it do, and why doesn't the build fail?  Should it become a
> BuildRequires?

ant is generating this error. jaxp_parser_impl is managed by alternatives and
provided by multiple packages, including java-1.4.2-gcj-compat and xerces-j2.
I don't understand why it's not set up properly in this build environment.

The reason the build doesn't fail is because libgcj.jar contains all of the
classes provided by jaxp_parser_impl.  java-1.4.2-gcj-compat simply symlinks
jaxp_parser_impl.jar to libgcj.jar.  Perhaps the build would fail if you tried
building using the Sun VM alternative.

I'm hoping fitzsim has some insight into why the jamp_parser_impl alternative is
broken.

(In reply to comment #6) 
> (In reply to comment #4) 
>  
> > %ghost %doc %{_javadocdir}/%{name} 
> > What is the purpose of this?  This looks extremely odd. 
>  
> To be honest, I'm not sure.  It's just established practice for FC java   
> packages. 
 
The original intention in JPackage (where the practice was inherited from) was 
to be able to install multiple versions of javadocs for a package in parallel, 
and to have an unversioned symlink pointing at the last installed version. 
 
However, there are several major flaws with the current JPackage (and FC, and 
the one in this package) implementation, to name a few: 
 
- It doesn't work.  The symlinks cause a rpm conflict between different 
versions of the javadoc packages, even when %ghost'd. 
 
- It requires write access to %{_javadocdir} in %post and expects to succeed 
-> breaks in %{_netsharedpath} setups where /usr/share is (NFS) mounted read 
only. 
 
- The idea of "last version installed" is not very good in the first place.  
"Newest" could be slightly more useful. 
 
However, the unversioned %{_javadocdir}/%{name} is very useful eg. for javadoc 
crosslinking between packages as well as bookmarking, IDE config etc. 
 
For now, I'd suggest packaging %{_javadocdir}/%{name} as usual (not %ghost), 
and removing the %post javadoc scriptlet altogether. 

(In reply to comment #8)
> For now, I'd suggest packaging %{_javadocdir}/%{name} as usual (not %ghost), 
> and removing the %post javadoc scriptlet altogether. 

Ok, done.  I've placed a revised spec file and srpm here:

http://spindazzle.org/FE/devel

Looks good enough, go ahead and import the changes.  Don't forget to add
%{?dist} after the number in the Release tag before you request another build. 
Do you want this in FE4 too?

(In reply to comment #10)
> Looks good enough, go ahead and import the changes.  Don't forget to add
> %{?dist} after the number in the Release tag before you request another build. 

Thanks! Done.

> Do you want this in FE4 too?

No, FE5 is fine for now.  Thanks again.  

*** This bug has been marked as a duplicate of bug 690282 ***