Re: xlibmesa naming and relationships
On Son, 2003-02-02 at 15:05, Marcelo E. Magallon wrote:
>
> >> Michel Dänzer <daenzer@debian.org> writes:
>
> > > I still don't get it. There's no incompatibility between
> > > xlibmesa3-gl, xlibmesa4-gl and xlibmesa5-gl to come, so what's the
> > > point of the different names? The worst thing IMHO is
> > > x-window-system-core depending on one particular of these, but I
> > > think it would be much easier for everyone if we had a common name
> > > which reflects the libGL API used.
>
> Don't look at me. The "3" in the mesa packages makes me puke. It's
> old historical baggage (you probably know why it's there in the first
> place -- but don't ask me why the xlibmesa packages have that ugly 3 or
> 4 or whatever in them). As you are well aware of, changing a package's
> name in Debian is next to impossilbe.
Shouldn't be a problem because nothing outside of the xfree86 source
package should depend on the xlibmesa packages directly (or deal with
it)?
> > Also, what's with changing the semantics of the libgl1 virtual
> > package? Shouldn't a new one like libgl1-noglu be introduced?
[...]
> Recap: the reason why *I* split the GLU bits out of the mesa packages
> is because all the mesa packages were duplicating the functionality
> (that is, each and every mesa package provide libGL and libGLU). I'd
> like to make it possible to install multiple mesa packages at the same
> time, mostly because I expect to provide ES packages in the future
What's ES? The best guess I can come up with is Embedded Systems.
> (I got to get myself a Radeon before that happens[0]) and that's just
> easier if I have a separate GLU package. The other reason was to have
> a GLU package that the nvidia packages can depend on. I *hate* the way
> the current packages work (depending on the xlibmesa packages just to
> divert their libGL files out of the way).
I don't have anything against the separate GLU packages, on the
contrary, I appreciate it a lot for the DRI snapshot packages, where I
had to use similar ugly tricks.
My point is that the semantics of the libgl1 virtual package have
changed from 'libGL.so.1 and libGLU.so.1' to 'libGL.so.1 only', which
breaks packages that depend on libgl1 only but need libGLU. Did you
consider this, and what were your plans to handle it?
> [0] The reason why I don't own a Radeon atm is the sorry state of Linux
> drivers. No, TNL isn't enough. If I get myself a radeon, I'd like
> to be able to use fragment programs. I won't pay EUR 400 for a
> card if I can only use 30% of its functionality. The DRI drivers
> don't support that and the ATI drivers are, well, lacking wrt to
> the DRI ones. I do intend to roll up my sleeves, but not right
> now.
It's a shame indeed, hopefully ATI will provide documentation for those
advanced features in time, but I think the lower end cards still provide
good performance.
> [1] I don't actually have a problem with just depending on XFree86's
> libGLU (now that it's been splitted off, that is); it's only that
> Mesa releases faster than XFree86 and *if* someone sometime submits
> fixes to libGLU, they are probably going to show up first in Mesa's
> version and then in XFree86's.
Agreed.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Reply to: