Bug 107228

The freeglut in the tree right now probably sucks rocks.  ;o)

It was put in the tree a long time ago with the intent to replace it
with freeglut 2.0.0 when it came out.  Unfortunately freeglut development
lagged and 2.0.0 wasn't released in time to be included in the distribution.

That left me with 2 choices more or less:

1) Remove the freeglut 1.3 from the tree, ship no glut or freeglut at all,
   and then wait for freeglut 2.0.0 to be released, add it to rawhide for
   the next distribution release.  This would mean Fedora Core 1 has no
   glut or freeglut at all, and users need to wait for Fedora Core 2 for
   a glut implementation to show up.

or

2) Leave the more or less untested and possibly broken freeglut in the tree
   so that it is part of the distribution, possibly investigate fixing bugs
   in it that get reported during Fedora Core 1 development, and later on
   when 2.0.0 comes out, provide an update if it is technically feasible
   and we have the time to do so.

I favoured #2 personally even though I knew freeglut 1.3 might not really
be that useful to people as is, and it didn't hurt to leave it around and
see what reports got received about it.  Your bug report is the very first
bug report about freeglut.  ;o)

freeglut 1.3 is very old now, and not worth even investigating any problems
in it IMHO or fixing them, since 2.0.0 is out now and dramatically improved.
Unfortunately, I wont have any engineering time to spend on freeglut for at
least 3-4 weeks, possibly longer, so this means freeglut 2.0.0 wont get into
Fedora Core 1 unfortunately.

I need to either remove freeglut 1.3 completely and wait for Fedora Core 2
to ship freeglut, or leave 1.3 in anyway since this is the first bug report
received, so probably nobody has even tried it in the last 4-6 months or
so.  ;o)  If I leave it in, then I can probably ship a working freeglut
2.0.0 as erratum sometime after Fedora Core 1 ships.

This is a bit klunky of a decision to make, and pretty much anyone would
agree with that.  Based on purely technical grounds, and on "correctness",
I would remove freeglut now.  Based on what is best for freeglut, and thus
us having a solid glut substitute as soon as possible, I'd like to include
freeglut anyway.

Rather than make the decision myself however, I'd like to get other people's
opinions and feedback, including our development team.  I'll probably go with
whatever decision seems to be the most popular, unless there are very strong
objections from someone out there.

What's your opinion?

My own software will probably never build with freeglut 1.3, because that
version doesn't provide drop-in replacements for the glut header and library.
This is corrected in version 2.0. So even if this particular issue were fixed, I
don't think it would end up meaning much for me. But since I like the idea of
having version 2.0 in the distribution sooner rather than later, I'd vote for
leaving 1.3 in--broken or not.

I care about glut support also. I am trying to build a program survex on Fedora
that needs glut. I was unsuccessful hacking the program to use the freeglut
stuff. It sounds like 2.0 is the way to go since that solves the name problem at
least :)

Glaxium won't build on FC1 due to missing headers etc.. I'm going to
attempt to build a freeglut2 RPM set based on the current spec.

Pretty much anything that needs GLUT at all probably won't compile in
Fedora Core 1, because we do not ship glut at all, and our
freeglut is just a placeholder to allow me to provide an updated
freeglut later on for FC1.

I included the current freeglut just to give me the option to upgrade
freeglut when the final 2.x release came out, but it took too long to
make the FC1 cut.  I hope to be able to release freeglut 2.x in a
couple months though.

Hope this helps.

I've built an RPM for freeglut-2.0.1 (and updated the spec
appropriately). It can be found at
http://jumpgate.homelinux.net/random for those who are interested.

Seems reasonably stable and it has allowed me to build and run Glaxium
- YMMV.

*** Bug 115069 has been marked as a duplicate of this bug. ***

As an update to this report (and duplicates), the current status
on freeglut, is that I plan on having the newest freeglut present
in Fedora Core 2, as well as having it in as many beta releases
as I can, time permitting.

Right now, my priorities are involved in XFree86 issues and other
stuff that is high priority, however I will revisit this in the
not distant future.  Once freeglut has seen enough testing in
Fedora development and/or beta releases, I may release it as
an update for Fedora Core 1 as well.

I'll update this report when I have official rpms ready for end
user testing.

Thanks for your continued patience.

Specfile and rpms for FC1, RH9, RH8.0 and RH7.3 can be found at

http://atrpms.physik.fu-berlin.de/name/freeglut/

The packages are based on Andy Piper's specfile (see comment #6)
adding some BuildRequires, glut(-devel) compatibility Provides and
moving *.so to the -devel package.

See also http://bugzilla.atrpms.net/show_bug.cgi?id=22

Please use a higher release than found there, if/when this package
makes it in FC2/FC1 to allow for proper upgrade paths.

I would really like the above to make it into FC2 and have it also
released for FC1 as an update, as like many have already said,
freeglut 1.3 is basically useless as a replacement for glut, but the
newer 2.0 works fine.
Important also are the provides for glut and glut-devel, as this will
allow older packages explicitely requiring those to still work. Maybe
having the obsoletes versionned would be a good idea too.

Axel) Great, I'll have a look at them some time soon.  My plans
were to have the glut compatibility split out into subpackages,
so that someone can install freeglut itself, then optionally
install freeglut-glut-compat (or whatever it would be called),
and have the compat package do virtual provides for the old
glut, so that it is a 100% drop in compatible package (bugs aside).
The changes in the comments you provided, and the bug report sound
totally in line with what my own intentions were, so this is
probably what I will end up doing.

When I include the freeglut update, I will bump the release field
up a notch or two so that it obsoletes the external package (even
though we do not normally do this, it wont hurt in this case).


Mattias) Indeed, that is the plan, just as I've stated above in
comment #8.  Remember, the only reason freeglut got into FC1 was
as a (mostly useless) placeholder to reserve the right to update
it in the future.  ;o)

Your comments about doing the virtual provides are also correct,
and that is what I will do.  Again, my goal is to be as compatible
with glut as we can, both on the source code level (API), the
binary level (ABI), and also on an rpm packaging level.

I will try to get this into the tree soon, and update this report
again.

Thanks for the info and suggestions guys.

I've taken the current atrpma freeglut src.rpm for FC1, and have
made some minor Red Hattified modifications to it.  The package
builds locally, but died in our buildsystem on ia64.  The problem
appears to be an ia64 buildsystem transient problem requiring
release engineering folks to fix, but it's 2am, so I wont be able
to produce rawhide packages until tomorrow at the earliest.

I thought I'd provide this status update as a heads up for would-be
testers.

Thanks in advance.

freeglut-2.2.0-10 is now available for Fedora devel for download via
'yum' and ftp at the following URL:

    ftp://people.redhat.com/mharris/testing/unstable

The package may be recompiled for FC1 also.  I recommend using a
lower Release: number if you rebuild it for FC1.

Please test this as best you can.  At some point I will likely
release it as erratum for FC1 also.

Works great for me as a drop-in replacement for glut on FC1. I had
previously installed the last Red Hat Linux 9 glut packages. I haven't
got any 3D acceleration, so I can't really fully test (ATI Radeon
Mobility 9600, grrr), so if anyone wants to, there are FC1 rebuilds here :

http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/testing/1/freeglut/

Just one small remark : Would it be possible to change the "Obsoletes:
glut" to "Obsoletes: glut <= 3.7"? This is just because no one can
predict the future, and if glut changes its license in future
versions, merges with freeglut etc. then it'll still be possible to
re-introduce glut packages easily. Non-versionned obsoletes are evil
in general anyhow. Oh, and same remark for the devel sub-package.

I haven't yet tried to rebuild packages that required glut-devel
against it to see if it works fine. Probably worth testing.

freeglut-2.2.0-10 is currently in Fedora Core devel, and will be
in FC2test2 release.

Closing issue as 'RAWHIDE'.  Thanks to everyone for their
patience.


Matthias:  Thanks for the Obsoletes suggestion. I've added the
versioned obsolete lines to freeglut in our internal cvs repository,
and the changes will be in freeglut-2.2.0-11, which will be built
once test2 is out the door and our head tree reopens for such
changes.  I've made a note to myself to build the -11 package once
the tree is open again, but if you'd like to file a separate bug
tracker for that issue, that would also be fine.   Thanks again.