Bug 526426 - Review Request: libgle - A Tubing and Extrusion Library for OpenGL
Summary: Review Request: libgle - A Tubing and Extrusion Library for OpenGL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Thomas Fitzsimmons
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 541764 (view as bug list)
Depends On:
Blocks: 541765
TreeView+ depends on / blocked
 
Reported: 2009-09-30 08:40 UTC by Mary Ellen Foster
Modified: 2010-02-06 00:01 UTC (History)
4 users (show)

Fixed In Version: 3.1.0-4.fc12
Clone Of:
Environment:
Last Closed: 2010-02-06 00:00:33 UTC
Type: ---
Embargoed:
fitzsim: fedora-review+
j: fedora-cvs+


Attachments (Terms of Use)
my libgle.spec (1.56 KB, application/octet-stream)
2009-09-30 09:34 UTC, Ralf Corsepius
no flags Details
Patch to make libgle's Makefile.examples libtool-independent. (1.17 KB, patch)
2009-12-03 17:26 UTC, Thomas Fitzsimmons
no flags Details | Diff

Description Mary Ellen Foster 2009-09-30 08:40:04 UTC
Spec URL: http://mef.fedorapeople.org/packages/OpenGL-gle/OpenGL-gle.spec
SRPM URL: http://mef.fedorapeople.org/packages/OpenGL-gle/OpenGL-gle-3.1.0-1.src.rpm

Description:
The GLE Tubing and Extrusion Library consists of a number of "C"
language subroutines for drawing tubing and extrusions. It is a very
fast implementation of these shapes, outperforming all other
implementations, most by orders of magnitude. It uses the
OpenGL (TM) programming API to perform the actual drawing of the tubing
and extrusions.

Note that there is already a package in Fedora called "gle" (the "Graphics Layout Engine"). Alternate name suggestions for this package are very welcome.

Comment 1 Ralf Corsepius 2009-09-30 09:01:30 UTC
Am I correct in assuming that this package is identical to libgle (which already in Fedora)?

Comment 2 Ralf Corsepius 2009-09-30 09:03:45 UTC
(In reply to comment #1)
> Am I correct in assuming that this package is identical to libgle (which
> already in Fedora)?
Replying to myself: I was in error, the libgle package I have installed is 
one of my local packages ... Appologies :)

Comment 3 Mary Ellen Foster 2009-09-30 09:11:28 UTC
(In reply to comment #2)
> Replying to myself: I was in error, the libgle package I have installed is 
> one of my local packages ... Appologies :)  

Well, if you've already got a spec file for this, I'm glad to combine efforts.

Comment 4 Ralf Corsepius 2009-09-30 09:34:35 UTC
Created attachment 363160 [details]
my libgle.spec

NB1: My spec file isn't 100% clean either, because I so far have not intented to submit it to fedora :)

NB2: Many of the "multilib/install" issues you seem to have with your spec-file originates from you not using %configure and make DESTDIR=... install.

Comment 5 Mary Ellen Foster 2009-09-30 09:53:53 UTC
Thanks for that -- I'm not sure how I ended up with the strange collection of sed commands I was using before. :) (This is what happens when you start with the upstream spec file and try to incrementally modify it ...)

New version:
http://mef.fedorapeople.org/packages/OpenGL-gle/OpenGL-gle.spec
http://mef.fedorapeople.org/packages/OpenGL-gle/OpenGL-gle-3.1.0-2.src.rpm

Comment 6 Ralf Corsepius 2009-10-04 05:06:25 UTC
One question: Why do you name the package OpenGL-gle?

The upstream tarball is named "gle", so naming this package "gle" or "libgle" would be natural choices to me.

Comment 7 Mary Ellen Foster 2009-10-04 06:47:47 UTC
"gle" is already taken in Fedora -- "libgle" sounds like a better idea though and I'll probably rename it shortly.

Comment 8 Ralf Corsepius 2009-11-27 10:08:31 UTC
*** Bug 541764 has been marked as a duplicate of this bug. ***

Comment 9 Thomas Fitzsimmons 2009-11-27 21:18:41 UTC
I also packaged this independently.  I compared our three versions.  Here are my suggestions for a combined package.

I like gle as a name, but since that's already taken, libgle is fine.

The license field is complicated.  The closest representation I came up with is:

License: GPLv2+ or (Artistic clarified and MIT)

where MIT is an approximation of:

gle-3.1.0/src/COPYING.src

which, as far as I can tell, is an IBM MIT-like license that's not present in Fedora's list:

http://fedoraproject.org/wiki/Licensing#SoftwareLicenses

URL and Source0 should point to gle's new home:

URL:            http://linas.org/gle/
Source0:        http://linas.org/gle/pub/gle-%{version}.tar.gz

Ralf got the minimal set of BuildRequires but since this is a Fedora package, I prefer to reference the actual dependencies directly, rather than use virtual provides:

BuildRequires: mesa-libGL-devel
BuildRequires: freeglut-devel
BuildRequires: libXmu-devel
BuildRequires: libXi-devel

The guidelines don't mention anything about not referencing virtual provides, so this is a personal preference (the choice between compatibility with other distros and future-proofing wrt to Fedora).

I like Ralf's use of --disable-static rather than deleting the .a file after the build.

To be explicit I added:

Requires(post):   /sbin/ldconfig
Requires(postun): /sbin/ldconfig

but the guidelines don't mention that:

https://fedoraproject.org/wiki/Packaging/Guidelines#Shared_Libraries

so omitting them is fine.

I think Ralf's package is the closest to complete.  It only needs the License, URL and Source0 (and possibly BuildRequires) changes.

Who wants to be the libgle maintainer for Fedora?  I'd prefer not to be; I only packaged GLE because it is a dependency of NanoEngineer-1:

https://bugzilla.redhat.com/show_bug.cgi?id=541765

which I do want to maintain.

Comment 10 Mary Ellen Foster 2009-11-27 21:22:57 UTC
Thomas -- I'm willing to be the maintainer; I'll incorporate changes from Ralf's package as appropriate. Want to swap reviews?

Comment 11 Thomas Fitzsimmons 2009-11-27 23:42:32 UTC
(In reply to comment #10)
> Thomas -- I'm willing to be the maintainer; I'll incorporate changes from
> Ralf's package as appropriate. Want to swap reviews?  

Sure!

Comment 12 Mary Ellen Foster 2009-11-30 11:26:58 UTC
I've made a couple more updates to the package following the above comments:
- use --disable-static on the build
- tidy up the BuildRequires
- rename to libgle

The result is here:
http://mef.fedorapeople.org/packages/libgle/libgle-3.1.0-3.src.rpm
http://mef.fedorapeople.org/packages/libgle/libgle.spec

Comment 13 Thomas Fitzsimmons 2009-12-02 07:01:10 UTC
$ rpmlint libgle-3.1.0-3.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint RPMS/i586/libgle-3.1.0-3.i586.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint RPMS/i586/libgle-devel-3.1.0-3.i586.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint RPMS/i586/libgle-debuginfo-3.1.0-3.i586.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

There's a trailing space at the end of the second BuildRequires line.  Personally I prefer one BuildRequires line per requirement.

What's the reason for the mesa-libGL-devel requirement in the devel sub-package?  Also, shouldn't the base package requirement include the -%{release} component?

Requires: %{name} = %{version}-%{release}

The trademark in the description has to go:

https://fedoraproject.org/wiki/Packaging/Guidelines#Trademarks_in_Summary_or_Description

$ md5sum SOURCES/gle-3.1.0.tar.gz 
da5b45c6906343d4a3672c3de35513ad  SOURCES/gle-3.1.0.tar.gz

$ wget http://www.linas.org/gle/pub/gle-3.1.0.tar.gz
--2009-12-01 22:19:05--  http://www.linas.org/gle/pub/gle-3.1.0.tar.gz
Resolving www.linas.org... 99.153.64.178
Connecting to www.linas.org|99.153.64.178|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 806861 (788K) [application/x-gzip]
Saving to: `gle-3.1.0.tar.gz'

100%[======================================>] 806,861      112K/s   in 7.6s    

2009-12-01 22:19:14 (104 KB/s) - `gle-3.1.0.tar.gz' saved [806861/806861]

$ md5sum gle-3.1.0.tar.gz 
da5b45c6906343d4a3672c3de35513ad  gle-3.1.0.tar.gz

Other than the issues noted above everything from the Review Guidelines is fine.

https://fedoraproject.org/wiki/Packaging:ReviewGuidelines

I built the packages in mock on i586.  They install properly and I tested them against my NanoEngineer-1 packages.

I'm going to approve this.  Please make the suggested fixes before building the package into Rawhide.

Comment 14 Ralf Corsepius 2009-12-02 07:32:41 UTC
(In reply to comment #13)
> What's the reason for the mesa-libGL-devel requirement in the devel
> sub-package?
It should be
Requires: libGL-devel
because the package doesn't actually depend upon Mesa's libGL-devel, but upon an arbitrary package which provides "libGL-devel"

>  Also, shouldn't the base package requirement include the
> -%{release} component?
It should.

Comment 15 Thomas Fitzsimmons 2009-12-02 07:57:54 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > What's the reason for the mesa-libGL-devel requirement in the devel
> > sub-package?
> It should be
> Requires: libGL-devel
> because the package doesn't actually depend upon Mesa's libGL-devel, but upon
> an arbitrary package which provides "libGL-devel"

Requiring libGL-devel versus mesa-libGL-devel is fine by me.  But why does libgle-devel explicitly require libGL-devel?  gle.h doesn't include any other include files.

My gle-devel package required xorg-x11-proto-devel and did not own the /usr/include/GL directory, but I think having libgle-devel own /usr/include/GL is better.  But I don't understand the libGL-devel requirement, since libGL-devel isn't required to build against libgle.

Comment 16 Ralf Corsepius 2009-12-02 09:19:25 UTC
(In reply to comment #15)
> (In reply to comment #14)

> Requiring libGL-devel versus mesa-libGL-devel is fine by me.  But why does
> libgle-devel explicitly require libGL-devel?  gle.h doesn't include any other
> include files.
Correct, but ... the situation actually is more difficult:



# nm -D --undefined /usr/lib64/libgle.so
                 w _Jv_RegisterClasses
                 U __cxa_atexit
                 w __cxa_finalize
                 U __fprintf_chk
                 w __gmon_start__
                 U acos
                 U atan2
                 U free
                 U glBegin
                 U glColor3fv
                 U glColor4fv
                 U glEnd
                 U glIsEnabled
                 U glMultMatrixd
                 U glNormal3dv
                 U glPopMatrix
                 U glPushMatrix
                 U glTexCoord2d
                 U glVertex3dv
                 U gluBeginPolygon
                 U gluDeleteTess
                 U gluEndPolygon
                 U gluNewTess
                 U gluTessCallback
                 U gluTessVertex
                 U malloc
                 U realloc
                 U sincos
                 U sqrt
                 U stderr

=> There are hidden deps on libGL and libGLU.

I am not sure (yet) how to handle this. A couple of real world use cases of libgle would easily clearify the issue.

> My gle-devel package required xorg-x11-proto-devel and did not own the
> /usr/include/GL directory, but I think having libgle-devel own /usr/include/GL
> is better.
That's a different (unresolved) problem: Ownership of the /usr/include/GL.

In general, the current rule is: 
If package A depends on another package B which provides a directory, package A wants to install files into, then it is sufficient for package A to "R: B".
If package A does not depend upon package B, then package B must own this directory (The directory would be owned by both A and B, then).

Comment 17 Thomas Fitzsimmons 2009-12-03 17:26:57 UTC
Created attachment 375849 [details]
Patch to make libgle's Makefile.examples libtool-independent.

Here is a patch to examples/Makefile.examples to allow building the examples after the -devel package has been installed.

cp -r /usr/share/doc/libgle-devel-3.1.0/examples/ ~
cd ~/examples
make -f Makefile.examples

Mary, can you add this patch to the RPM?

Here's a sample compilation (resulting binary worked on i586):

gcc -c -o mainsimple.o mainsimple.c
...
gcc -c -o helix.o helix.c
cc -g -O2 -Wall  -o helix  helix.o mainsimple.o -lgle -lglut -lGLU -lGL -lXmu -lXi -lXext -lXmu -lXt -lX11 -lm

I think this answers the questions of what -devel packages libgle-devel should require, and also that it should not own /usr/include/GL since it will be installed by the libX11-devel -> xorg-x11-proto-devel dependency chain.

Comment 18 Mary Ellen Foster 2010-01-13 10:49:37 UTC
Hi! I've sort of lost track of this over the holidays, and I want to finish it off -- what is the consensus on what package(s) to Requires in the -devel package?

Comment 19 Thomas Fitzsimmons 2010-01-13 20:17:14 UTC
libgle-devel should require all the libraries listed on the example link line.

[fitzsim@autumn ~]$ rpm -qf /usr/lib/libgle.so
libgle-devel-3.1.0-3.i586
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libglut.so
freeglut-devel-2.6.0-0.2.rc1.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libGLU.so
mesa-libGLU-devel-7.6-0.13.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libGL.so
mesa-libGL-devel-7.6-0.13.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libXmu.so
libXmu-devel-1.0.5-1.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libXi.so
libXi-devel-1.3-1.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libXext.so
libXext-devel-1.1-1.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libXmu.so
libXmu-devel-1.0.5-1.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libXt.so
libXt-devel-1.0.7-1.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libX11.so
libX11-devel-1.3-1.fc12.i686
[fitzsim@autumn ~]$ rpm -qf /usr/lib/libm.so
glibc-devel-2.11-2.i686

The package list is: glut-devel, libGLU-devel, libGL-devel, libXmu-devel, libXi-devel, libXext-devel, libXmu-devel libXt-devel, libX11-devel.

Comment 20 Mary Ellen Foster 2010-01-18 11:57:28 UTC
Okay, here's a new version with the patch from comment 17 and with the requirements on the -devel package modified; I also removed the trademark from the description line:

http://mef.fedorapeople.org/packages/libgle/libgle-3.1.0-4.src.rpm
http://mef.fedorapeople.org/packages/libgle/libgle.spec

Comment 21 Thomas Fitzsimmons 2010-01-18 17:23:53 UTC
Approved.  Please go ahead and add this package to the build system.

Comment 22 Mary Ellen Foster 2010-01-19 10:13:37 UTC
New Package CVS Request
=======================
Package Name: libgle
Short Description: A tubing and extrusion library for OpenGL
Owners: mef
Branches: F-12 F-11

Comment 23 Jason Tibbitts 2010-01-19 17:58:39 UTC
CVS done (by process-cvs-requests.py).

Comment 24 Fedora Update System 2010-01-20 10:07:55 UTC
libgle-3.1.0-4.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/libgle-3.1.0-4.fc12

Comment 25 Fedora Update System 2010-01-20 10:08:29 UTC
libgle-3.1.0-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/libgle-3.1.0-4.fc11

Comment 26 Fedora Update System 2010-01-21 00:09:50 UTC
libgle-3.1.0-4.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libgle'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0846

Comment 27 Fedora Update System 2010-01-21 00:10:53 UTC
libgle-3.1.0-4.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libgle'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0848

Comment 28 Fedora Update System 2010-02-06 00:00:26 UTC
libgle-3.1.0-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 29 Fedora Update System 2010-02-06 00:01:08 UTC
libgle-3.1.0-4.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


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