Bug 167482 - Review Request: jogl
Review Request: jogl
Status: CLOSED DUPLICATE of bug 690282
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Greg DeKoenigsberg
David Lawrence
https://jogl.dev.java.net/
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-09-02 20:46 EDT by Anthony Green
Modified: 2011-05-23 13:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-03 19:35:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony Green 2005-09-02 20:46:55 EDT
Spec Name or Url: http://spindazzle.org/FE/devel/jogl.spec
SRPM Name or Url: http://spindazzle.org/FE/devel/jogl-1.1.1-1.src.rpm
Description: Java bindings for the OpenGL API

The JOGL Project hosts a reference implementation of the Java bindings
for OpenGL API, and is designed to provide hardware-supported 3D
graphics to applications written in the Java programming language.  Is
is part of a suite of open-source technologies initiated bu the Game
Technology Group at Sun Microsystems.  JOGL provides full access to
the APIs in the OpenGL 1.5 specification as well as nearly all vendor
extensions, and integrated with the AWT and Swing widget sets.


This package includes both jar files and native (gcj) code.  It will work with both the gcj and Sun VM alternatives.  See http://fitzsim.org/blog/?p=7 for some detail.
Comment 1 Anthony Green 2005-09-02 20:58:54 EDT
*** Bug 167481 has been marked as a duplicate of this bug. ***
Comment 2 Warren Togami 2005-09-03 15:28:49 EDT
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
Comment 3 Anthony Green 2005-09-03 15:48:12 EDT
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.
Comment 4 Warren Togami 2005-09-03 16:05:16 EDT
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.
Comment 5 Warren Togami 2005-09-03 16:32:12 EDT
+ 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?
Comment 6 Anthony Green 2005-09-03 16:53:53 EDT
(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 :-)
Comment 7 Anthony Green 2005-09-03 16:58:45 EDT
(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.



Comment 8 Ville Skyttä 2005-09-03 17:24:33 EDT
(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. 
Comment 9 Anthony Green 2005-09-03 18:18:46 EDT
(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

Comment 10 Warren Togami 2005-09-03 18:22:12 EDT
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?
Comment 11 Anthony Green 2005-09-03 19:35:18 EDT
(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.  



Comment 12 Jason Tibbitts 2011-05-23 13:47:48 EDT

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

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