This issue has come up before in Red Hat Linux 7.0 and 7.1, and is bound
to come up again now, so I've decided to fully document the whole issue
here, so I can point other bug reports to this one later on, rather than
have new long drawn out threads every time a new person reports this.

Glide3 used to be a separate RPM package.  When it was a separate package,
many users complained, as you are now, that they don't have a 3dfx card,
and as such, should not need to install Glide3.  Those users are of course,
correct.  Nothing in XFree86 or otherwise technically requires Glide3 if
the system is not using a 3dfx Banshee or Voodoo 3/4/5 video card and
wanting to use DRI.  The dependancy thus technically, is on the XFree86
Mesa tdfx driver, not on XFree86 itself.  In other words, "yes, you
are correct".

However, it is much more complicated than that.  Let me explain...

What we need to guarantee, is that when a user who _does_ have a tdfx
card, installs, that Glide3 is present in order for DRI to work.  And
ultimately, that is why the dependancy is there, wether it is a separate
Glide3 package with a dep set in XFree86, or wether Glide3 is assimilated
into XFree86 as it was for Red Hat Linux 7.2.

Due to a few complaints such as this one, we decided to totally get rid of
the Glide3 package entirely and instead, package the Glide3 sources
directly into XFree86.  This solved the problem by both making Glide3
available to X during building, and also by making sure Glide3 was
installed on the system for 3dfx users at runtime, since Glide3 was
part of the XFree86-libs and XFree86-devel subpackages.  In short,
solve the "handful of users complaining" problem by hiding Glide3 in
the main XFree86 packages.

That worked great.  Since then not a single person has noticed nor
complained about Glide3 being installed on their system.  However,
that came with some trouble.  It was a huge pain in the arse to
integrate Glide3 into the XFree86 spec file, and build process and
work out all sorts of unforseen problems that just were never expected.
During that process we learned that it was more of a waste of engineering
resources to have done that, than to just tell people "sorry, but that
is the way it is".  The XFree86 spec file is a huge complex twisty maze
on its own, and Glide3 being in it, made it all the twistier.

Also, Glide3 being part of the XFree86 packages meant that I couldn't
offer an updated Glide3 package to people, if Glide3 got updated upstream.
That rarely happens though, so it wasn't considered critical.

Glide3, as we ship it, is not a general purpose library for applications
to link to, and as far as I know, nothing other than Mesa does link to
it.  It exists solely for the purpose of OpenGL hardware acceleration on
3dfx video hardware via the Mesa OpenGL library interfaces.  So for all
intents and purposes. Glide3 is "the Mesa 3dfx driver" which just happens
to be a separate package rather thanbeing part of Mesa sources.

Ultimately, the solution would be to get rid of Glide3 entirely, and
implement proper OpenGL drivers directly in Mesa, instead of Mesa just
acting like a wrapper library around Glide3.  That is a pipe dream that
simply will never happen however for many reasons, the main one being
that 3Dfx no longer exists, and developers consider the hardware obsolete
from a developmental standpoint.

So, Glide3 will basically exist and be shipped for as long as it builds
with low enough maintenance, and we consider 3Dfx hardware to be something
supported, including DRI support.  That will probably be many many Red Hat
Linux releases unless Glide3 breaks horribly and requires massive
engineering that nobody external is willing to do.

Our current XFree86 packaging contains all of the 2D XFree86 drivers in
one single package.  The alternative way of packaging would be to put
each driver into its own subpackage, with its docs, and whatnot.

Both ways of packaging have their own advantages and disadvantages. The
main advantage of separate package per driver, would be the ability to
only install what one truely needs, rather than installing a bunch of
video drivers that you'll never use.  If things were packaged like this
also, then such a dependancy on Glide3 could be made solely on the tdfx
driver subpackage, and only a user installing the tdfx driver would have
to install Glide3.  That ultimately is probably the best "technical"
packaging method IMHO, and yes, I'd like very much if things were packaged
that way myself.

The main problems with such packaging however, is maintainability and
customer technical support.  By having all drivers in one package, we
_know_ that a given user has the drivers installed for their video card,
whatever that card may be.  Change video hardware - rerun Xconfigurator,
and click click click, and startx - it just works.  No running for a CD,
or going to the ftpsite looking for files, and most important of all, to
me at least - no bogus bug reports filed because a user cant get their
card working, and ends up not having the driver installed.

The current method, the packaging is very simple, and the installation
and configuration tools are also quite simple.  Things just work, and
the only cost, is a few megs of wasted disk space.  The total space
required for all of the XFree86 2D video drivers combined, including
the video4linux driver is:

[root@asdf tmp]# du -sb /usr/X11R6/lib/modules/drivers/
2359296 /usr/X11R6/lib/modules/drivers

That's only 2.3 megabytes.  Splitting up the drivers into separate
packages so that the end user can only install the drivers they really
really need for their existing system, just to save 2 or so megabytes
of disk space is not a compelling reason for splitting up the drivers.
I absolutely hate to use the "diskspace is cheap" argument because it
is so lame, but really, it is quite true.  2Mb of disk space is a drop
in the ocean.  The benefits of having all drivers in one package very
much far outweigh the wasted space on a user's hard disk.

That is only the 2D drivers though. The DRI drivers themselves are
a bit larger than their 2D counterparts.

[root@asdf ssh]# ls -al /usr/X11R6/lib/modules/dri/
total 10824
drwxr-xr-x    2 root     root         4096 Feb  7 11:50 .
drwxr-xr-x    9 root     root         4096 Feb  7 12:27 ..
-rwxr-xr-x    1 root     root      1734365 Sep  6 00:24 gamma_dri.so
-rwxr-xr-x    1 root     root      1494076 Sep  6 00:24 i810_dri.so
-rwxr-xr-x    1 root     root      1544133 Sep  6 00:24 mga_dri.so
-rwxr-xr-x    1 root     root      1541895 Sep  6 00:24 r128_dri.so
-rwxr-xr-x    1 root     root      1547567 Sep  6 00:24 radeon_dri.so
-rwxr-xr-x    1 root     root      1461880 Sep  6 00:24 sis_dri.so
-rwxr-xr-x    1 root     root      1713575 Sep  6 00:24 tdfx_dri.so
[root@asdf ssh]# du -sb /usr/X11R6/lib/modules/dri/
11079680        /usr/X11R6/lib/modules/dri

An average of 1.5Mb per DRI driver at a total of approximately
11 megabytes.  While this is much larger than the 3D drivers, it
is still very much a drop in the water.  Glide3 is required by
the above tdfx DRI driver.  Glide3 itself, has a total size of
850k roughly.  So the total size of all of the 2D and 3D drivers
is basically 14.5Mb, which is extremely small in the 2002 age of
computing.

It makes no sense to allow a user to install only the 2D drivers
and not the 3D counterparts just for the reason of "greater choice
of the users of open source chocolaty goodness" IMHO, at the expense
of higher package maintenance resource cost, higher technical support
cost, and increase in the number of potential problems users,
especially new users would experience.

Even on older systems that are still considered supported, 15Mb is
not a compelling argument of savings to outweigh the benefit of having
all drivers installed and ready for use.  Glide3 in particular is only
850k.

So, in summary, as long as the XFree86 driver packaging remains
monolithic, the Glide3 dependancy will remain on the package for the
reasons described above, summarized as "maintainability, and
supportability".  The only way this dependancy will change, is if the
package eventually gets split up into subpackages per-driver, in which
case the Glide3 dependancy will move to the XFree86-tdfx-driver
subpackage or whatever it would be called.

The only way that this package subdivision will occur (if ever) is if
and when the configuration utilities get smart enough that they can
prompt a user for his/her CDROM, a drive path to install drivers from,
a URL, or via up2date.  This is something that I would indeed like to
see happen at some point in time, and is on my "potential new features
to add" list, but there are no current plans of implementing such.

Until we can somehow cover the supportability and maintainability
issues, it is much easier to require all users to install all drivers, including
Glide3.  Their voices are noted, and their complaints heard.

The issue is minor from this side of the fence however, and it is
possible that Glide3 and 3dfx hardware may be long since obsolete and
no longer supported by the time any of this ever changes, so it might
be a moot point.

I apologize for turning this into a book, but again, I suspect it to be
possible FAQ, so now this bug report can act as an answer for those
frequently asked questions, and a thread-killer for discussions on the
topic.  I hope this clarifies our position on Glide3 inclusion in
Red Hat Linux.

Thanks.