Re: mesag3 <-> xlibmesa-gl / libgl1-mesa-dri <-> xlibmesa-dri / libglu1-mesa <-> libglu1-xorg
On Thu, Sep 01, 2005 at 02:58:19PM +1000, Daniel Stone wrote:
> Right. My solution for that was to split them into a separate
> mesa-utils source package, with a slightly hacked Makefile. They
> build just fine independently.
Ah, you mean the utils! The demos are shipped in a separate tarball.
The programs in progs/util are not generally useful. I could include
them as examples in mesa-common or something like that.
And I don't know where glxinfo is going to end up. It's certainly not
included with mesa atm.
> The problem with Mesa Build-Depping on glut is so:
> * mesa depends on glut to build, which depends on libgl1-mesa-dev
> * buildd goes to install libgl1-mesa-dev to fulfill B-Ds
> * libgl1-mesa-dev deps mesa-common-dev (= ${Source-Version})
> * mesa-common-dev version n is in the archive from the maintainer
> upload
> * but libgl1-mesa-dev for, say, hppa, is still n-1
> -> uninstallable B-Ds
Uhm, are we talking about mesa (not "mesademos")?
Mesa-6.3.2$ find ! -type d -print0 | xargs -r0 grep glut.h
./Makefile: $(DIRECTORY)/include/GL/glut.h \
./docs/download.html:<a href="http://www.opengl.org/resources/libraries/glut.html";
./docs/README.WINDML:- src/ugl/ugl_glutshapes.c
./include/GL/gl.h: * including only glut.h, since glut.h depends on windows.h.
./include/GL/gl.h: * glut.h or gl.h.
./include/GL/uglglutshapes.h:/* uglglutshapes.h - Public header GLUT Shapes */
./progs/util/dumpstate.c:#include <GL/glut.h>
./progs/util/glstate.c:#include <GL/glut.h>
./progs/util/glutskel.c:#include <GL/glut.h>
Like I said before, those programs are not generally useful, at least
not in compiled form.
> As a short-term move, since we don't have Glide support in 6.3
> anyway, I just disabled the Glide packages and moved the headers
> across.
I decided that Glide is too much of a hassle. It will probably work
again in 6.4, that's true, but I have decided to carry with the plan I
had sketched a couple of years ago:
* Regular drivers are built from the mesa package
* Troublesome drivers (not being kept up to date, etc) are built
from a second source package (mesa-legacy)
* Whenever a new Mesa upstream is released, I look at it, if nothing
breaks (and this has happened multiple times -- recall that mesa
uses a x.y.z scheme, where odd y means "in development") then I
make an upload of the source package "mesa" to unstable
* If one of the "weird" drivers breaks in the new upstream, then
figure out if it's because of some small change. If that's the
case fix it. If not (as is the case with glide in 6.3) then
"move" the driver to the "mesa-legacy" package.
* Once I figure the driver is being actively maintained, move it
back to "mesa"
In this way I keep the same set of binary packages, meaning that users
won't be missing functionality, and I can keep the maintained drivers
up to date.
The mesa source package is structured in such a way that it allows for
building either mesa or mesa-legacy, after tweaking debian/control, of
course. There's a small duplication of code (the mesa and mesa-legacy
tarballs are sometimes the same file, sometimes not), but taking into
account that the binary packages are *much* larger than the source I
don't think that's something to gripe about.
Cheers,
--
Marcelo
Reply to: