[Bug 165992] Review Request: Glide3-Mesa - Render OpenGL through Glide3 for use with 3Dfx Voodoo 1 & 2

bugzilla at redhat.com bugzilla at redhat.com
Wed Aug 24 18:36:54 UTC 2005


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: Glide3-Mesa - Render OpenGL through Glide3 for use with 3Dfx Voodoo 1 & 2


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165992





------- Additional Comments From j.w.r.degoede at hhs.nl  2005-08-24 14:36 EST -------
In response to 1:
You should use %{?dist} in Release tag.

No I shouldnot it is not mandatory, and actually is pretty useless. What one
should do is make sure that ALL EVR's released for a certain FC version are all
older then all EVR's released for the next, so initial release would be:
FC3:   xxx-version-1
FC4:   xxx-version-2
devel: xxx-version-3

Then when an update is issued you get:
FC3:   xxx-version-1.1
FC4:   xxx-version-2.1
devel: xxx-version-4

Thats the only way to make sure upgrades will work reliable in all
circumstances, disttag is actually pretty useless.

With disttag one would get:

Initial release:
FC3:   xxx-version-1.fc3
FC4:   xxx-version-1.fc4
devel: xxx-version-1.fc5

FC5 gets released:
FC5:   xxx-version-2.fc5

Update (skip release 2 because that was used for Fc5 rebuild):
FC3:   xxx-version-3.fc3
FC4:   xxx-version-3.fc4
devel: xxx-version-3.fc5

No assume someone is running FC4, and runs yum update regulary, he will have
installed:
FC4:   xxx-version-3.fc4

Some weeks after the FC5 release he has heard no problems so he decides to
upgrade to FC5. He has a slow download, so he gets CD's from a friend including
FE cd's (oneday there will hopefully be FE isos), so he upgrades his system, but
the FE cd's contains the initial FE release which is xxx-version-2.fc5
He has installed xxx-version-3.fc4, which is newer, even though it has an older
disttag. So the upgrader won't upgrade xxx. Leaving him with an xxx build
against older libs which therefore might not work properly. And no dependencies
won't always catch this, dependencies although there are great are limited ibn
what they can do.

Notice how with my versioning scheme (which is also used by lots of other FE
maintainers) this problem does not exist.
I was actually going to ask why you used a disttag for xscorch, since IMHO
disttags are not all that good.

In response to 2:
Yes Glide3-devel package's not build by me contain a bug they install the
voodoo3 headers instead of the voodoo5 headers thus missing certain defines.
I have no plans to build this for FC3 since FC3's Glide release doesnot contain
glide binaries compiled for the Voodoo1 and 2 which are the very cards this is
package is intended for. (Glide3 from FC3 lacks glide-v2.so and glide-v1.so)

Please build/test this under atleast FC4 or even better Rawhide. The inital cvs
import of a package is always rawhide, so that really is where on should test.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the fedora-extras-list mailing list