On Thu, Feb 06, 2003 at 08:54:42AM +0100, Marcelo E. Magallon wrote: > I don't like the "3" is any of these packages (xlibmesa3, mesa3g, ...) > because it doesn't reflect *anything*. Not true, as you point out in the very next sentence. > In the case of mesa3g is just historical baggage and in the case of > xlibmesa3 it reflects something that's an (almost meaningless) > implementation detail. I do not personally feel that the major version number used by a software project is a meaningless detail. At least not in the case of Mesa, where they bump the major version number to reflect major new developments, like texture and lighting acceleration support. > The other reason why I hate that "3" is because I always forget where > it goes in the name (to the point that I'm almost sure I got it wrong > in what I just wrote). Well, I don't think anyone is telling you you have to use it. That I choose to places no gun to your head. > On Wed, Feb 05, 2003 at 03:24:07PM -0500, Branden Robinson replied: > > > > So, while I can't fault your logic of Mesa 3 being in 4.2.1 ... ;) > > > > Okay. I agree. Given that the soversion isn't terribly meaningful > > in the case of Mesa, in my opinion the library package name should > > communicate the major version number of Mesa itself. > > Well, actually the version (the shared object version, mind you) *is* > meaningful in the case of Mesa. It implements version 1.x of the > OpenGL API. If you don't know what that means, please go read *both* > the OpenGL 1.x spec and the GLX 1.x spec. Both are readly available at > http://www.opengl.org/ > > In short: the OpenGL API is fixed. It is extended via so called > "OpenGL extesions". Extensions are usally not visible as symbols being > exported by libGL.so.1 but instead there are specialized functions to > retreive the addresses of the requested code. Think dlopen if you > wish. Some extensions eventually make it to the core API and these > become available via the library (unfortunately). The current > implementation in Mesa corresponds *almost* to OpenGL 1.4, but the > library is still called libGL.so.1. Yes, I understand all of that. Thanks for reiterating it for the list, though. :) > I have been toying with the idea of creating virtual packages libgl1.1, > libgl1.2, libgl1.3 and so on, but I see downsides to it with very > little gain. I don't see any reason to do so either, as long as stuff compiled against one will work with others. > For the record: I dislike the proposal of using the Mesa version > present in XFree86 as part of the xlibmesaN package name. It's more than just a proposal, it's already impelemented. > Merging Mesa 5 in the XFree86 tree will happen RSN, and as far as I > understand Brian's intentions, there will be a Mesa 6... that would > mean changing the name of the package way too often. I don't feel that way. The FTP admins have been fairly quick to get new versions of XFree86 out of queue/new when I change things, and in any case I don't release new XFree86 packages every week, let alone do weekly releases that add, drop, or rename binary packages. -- G. Branden Robinson | It doesn't matter what you are Debian GNU/Linux | doing, emacs is always overkill. branden@debian.org | -- Stephen J. Carpenter http://people.debian.org/~branden/ |
Attachment:
pgpwstpSecxuL.pgp
Description: PGP signature