Re: xlibmesa naming and relationships
>> Michel Dänzer <daenzer@debian.org> writes:
> Shouldn't be a problem because nothing outside of the xfree86 source
> package should depend on the xlibmesa packages directly (or deal with
> it)?
You just have to convince apt that replacing the then dissapeared foo3
by foo1 just because the later also provides libgl1. You have to
resort to some trick to convince it to do the upgrade.
> > 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.
Yeah, the embedded version of Mesa. That thing TG is working on.
AFAICS, the source is going to be part of the Mesa tarball...
> 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?
Oh, that. I thought that the mail I wrote a couple of days ago ended
up in -x, too.
Basically the package providing libgl1 will depend on libglu1 for a
while to aid with upgrades. When packages are recompiled, they get a
dependency on libglu1 if they use it. Once most packages are
recompiled (for whatever reason), we file bugs on the rest.
> 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.
Sure, the drivers for the r100 (and r200 for the most part) are
perfectly usable.
--
Marcelo | Item 19: Differentiate among member functions, non-member
mmagallo@debian.org | functions, and friend functions
| -- Scott Meyers, Effective C++
Reply to: