Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: freeglut https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200172 ------- Additional Comments From mharris@xxxxxxxxxx 2006-07-26 04:50 EST ------- (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 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review