Bug 526426 - Review Request: libgle - A Tubing and Extrusion Library for OpenGL
Review Request: libgle - A Tubing and Extrusion Library for OpenGL
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
Fedora Extras Quality Assurance
:
: 541764 (view as bug list)
Depends On:
Blocks: 541765
  Show dependency treegraph
 
Reported: 2009-09-30 04:40 EDT by Mary Ellen Foster
Modified: 2010-02-05 19:01 EST (History)
4 users (show)

See Also:
Fixed In Version: 3.1.0-4.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-05 19:00:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
fitzsim: fedora‑review+
tibbs: fedora‑cvs+


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

  None (edit)
Description Mary Ellen Foster 2009-09-30 04:40:04 EDT
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 05:01:30 EDT
Am I correct in assuming that this package is identical to libgle (which already in Fedora)?
Comment 2 Ralf Corsepius 2009-09-30 05:03:45 EDT
(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 05:11:28 EDT
(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 05:34:35 EDT
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 05:53:53 EDT
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 01:06:25 EDT
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 02:47:47 EDT
"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 05:08:31 EST
*** Bug 541764 has been marked as a duplicate of this bug. ***
Comment 9 Thomas Fitzsimmons 2009-11-27 16:18:41 EST
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 16:22:57 EST
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 18:42:32 EST
(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 06:26:58 EST
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 02:01:10 EST
$ 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 02:32:41 EST
(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 02:57:54 EST
(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 04:19:25 EST
(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 12:26:57 EST
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 05:49:37 EST
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 15:17:14 EST
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 06:57:28 EST
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 12:23:53 EST
Approved.  Please go ahead and add this package to the build system.
Comment 22 Mary Ellen Foster 2010-01-19 05:13:37 EST
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 12:58:39 EST
CVS done (by process-cvs-requests.py).
Comment 24 Fedora Update System 2010-01-20 05:07:55 EST
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 05:08:29 EST
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-20 19:09:50 EST
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-20 19:10:53 EST
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-05 19:00:26 EST
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-05 19:01:08 EST
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.