I can review this.

* upstream source checks out:
6d16873bd876fbf4980a927cfbc496a1  freeglut-2.4.0.tar.gz

MUSTFIX items:
1.  Drop
BuildRequires: /sbin/ldconfig
(it's pretty much already a given)
Requires(post): /sbin/ldconfig
Requires(postun): /sbin/ldconfig
(rpm automatically picks these up)

2. Drop the 
CFLAGS="$RPM_OPT_FLAGS -Wall $(pkg-config --cflags glib)
it's not needed.  At some point in the past, freeglut may have had references to
glib's header files, but it doesn't anymore (I checked).

3.  omit static lib using 
%configure --disable-static
and drop from %files
%{_libdir}/lib*.a

4.  Optional.  Be careful about the Obsoletes/Provides.  It seemingly Obsoletes
itself using:
Obsoletes: glut <= 3.7
Provides:  glut  = 3.7
maybe use something safer like:
Obsoletes: glut < 3.7-%{release}
Provides:  glut = 3.7-%{release}
(and likewise for the Ob/Pr for glut-devel)

Or heck, drop the glut Obsoletes/Provides bits altogether, isn't glut pretty
much ancient history anyway?  (:


Fix 1-3, and I'll approve this.

Fixed 1 - 3 

Spec URL: http://www.knox.net.nz/~michael/freeglut.spec
SRPM URL: http://www.knox.net.nz/~michael/freeglut-2.4.0-9.src.rpm

CFLAGS="$RPM_OPT_FLAGS" was still needed, otherwise the buidl failed, but
dropped the glib cruff tho. 

As for item 4, I would like to hear what Mike Harris has to say, if nots not
required, I would like to remove it from the spec. 

> CFLAGS="$RPM_OPT_FLAGS" was still needed, otherwise the buidl failed, but
> dropped the glib cruff tho. 

??? Really??  I just built it in a fedora-6 mock buildroot just fine without it.

No biggie, either way, APPROVED.

Cool, thanks for the review. 


All checked in and built. 

(In reply to comment #2)

> 4.  Optional.  Be careful about the Obsoletes/Provides.  It seemingly Obsoletes
> itself using:
> Obsoletes: glut <= 3.7
> Provides:  glut  = 3.7
> maybe use something safer like:
> Obsoletes: glut < 3.7-%{release}
> Provides:  glut = 3.7-%{release}
> (and likewise for the Ob/Pr for glut-devel)
 
> Or heck, drop the glut Obsoletes/Provides bits altogether, isn't glut pretty
> much ancient history anyway?  (:
Nope, glut isn't ancient history. freeglut is an alternative to/replacement for
glut.

Therefore packages using GLut often Requires: glut-devel, because they depend on
a package providing a Glut API and do not depend on freeglut/freeglut-devel.

(In reply to comment #2)
> * upstream source checks out:
> 6d16873bd876fbf4980a927cfbc496a1  freeglut-2.4.0.tar.gz
> 
> MUSTFIX items:
> 1.  Drop
> BuildRequires: /sbin/ldconfig
> (it's pretty much already a given)
> Requires(post): /sbin/ldconfig
> Requires(postun): /sbin/ldconfig
> (rpm automatically picks these up)

There is nothing wrong with being explicit with these.

> 2. Drop the 
> CFLAGS="$RPM_OPT_FLAGS -Wall $(pkg-config --cflags glib)
> it's not needed.  At some point in the past, freeglut may have had references to
> glib's header files, but it doesn't anymore (I checked).

As long as it compiles ok without that now, and RPM_OPT_FLAGS can be
confirmed in the build log, I agree.

> 3.  omit static lib using 
> %configure --disable-static
> and drop from %files
> %{_libdir}/lib*.a

Definitely.  I'm surprised that I did not notice that myself.
 
> 4.  Optional.  Be careful about the Obsoletes/Provides.  It seemingly Obsoletes
> itself using:
> Obsoletes: glut <= 3.7
> Provides:  glut  = 3.7
> maybe use something safer like:
> Obsoletes: glut < 3.7-%{release}
> Provides:  glut = 3.7-%{release}
> (and likewise for the Ob/Pr for glut-devel)

The intent of this part, is to make absolutely sure that the old "glut"
and "glut-devel" packages that used to exist in Red Hat Linux, RHEL,
etc. are obsoleted and removed on upgrades.  Also, that freeglut now
provides this 100% compatible API and ABI, and to specify the version
to match the old glut package.  It seems to have worked for several
OS releases so far, however if there is a real bug present, then it
should be fixed while also retaining the original intent of the Provides
and Obsoletes.  Here is what we need in English:

In the runtime package:
Provides: <100% glut 3.7 compatible ABI>
Obsoletes: <the old official glut runtime package by Mark J. Kilgard>

In the devel package:
Provides: <100% glut 3.7 compatible API>
Obsoletes: <the old official glut-devel package by Mark J. Kilgard>

 
> Or heck, drop the glut Obsoletes/Provides bits altogether, 

That would seriously break the package.  freeglut is 2 things:

1) A 100% API and ABI compatible implementation of Mark J. Kilgard's GLUT

2) A new and improved alternative API/ABI which is a superset of GLUT.

Applications which link against libglut get #1, and applications that link
against libfreeglut get the new API.


> isn't glut pretty much ancient history anyway?  (:

GLUT isn't ancient history by any far shot.  There is quite a lot of
software out there which uses the GLUT api.  The official GLUT library
contains a license which is not open source however, so when we discovered
this, we had to drop the official GLUT from the distro.  There was lots
of software out there that uses GLUT however, and lots of users and customers
who write software that uses GLUT, so we needed a GLUT alternative.  I
discovered the freeglut project, and at the time it wasn't 100% compatible,
however the 2.2 version finally achieved reasonable compatibility with
the official GLUT.  We included freeglut in Fedora at that point to have
a compatible implementation, both because things in the OS itself linked
to libglut, but also because of the end user demand.

There are alternative solutions out there to GLUT though, such as SDL and
others, and personally I think new software should be written to a more
modern API, however there's still tonnes of existing software out there
that does use GLUT, so having freeglut available to Fedora users is still
important.

The main reason for moving it from Core to Extras, is that Core no longer
contains any software which links to it.  Another reason however, is that
while the upstream freeglut project does still develop freeglut reasonably
actively, they do not provide release-early/release-often style updates
to their software.  It's an open project, but they develop mainly in
Win32, and aren't as savvy with open source project maintenance concepts.
Since nothing in Core uses it anymore, it makes more sense to have it
in Extras where things do link to it, and it makes a bit more sense to
have someone who uses the library maintaining it, as they're more likely
to give it more love.

I fixed mesa to not require glut, and ajax is building a new package. Once
it is ready, we'll be able to disable freeglut in core, so hopefully the
Extras package will be built and ready then so Extras apps don't get
broken.  Make sure the "glut" and "glut-devel" deps are kept intact
as to the original intention, so that applications which use the GLUT
API or ABI can remain GLUT implementation agnostic.   There are actually
3 GLUT implementations out there now - the original GLUT, freeglut, and
a fork of freeglut named openglut (which is not 100% compatible per se.)

Thanks for taking this on guys!  You'll likely find that freeglut does not
require much package maintenance.  There's only one bug open on it right now,
and it's probably trivial to pull the fix out of CVS:

Bug #187642

Thanks again,
TTYL