On Sun, 2005-09-04 at 09:04 -0600, Marcelo E. Magallon wrote: > 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.
Ah, yes, sorry. > 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. Hm? progs/xdemos/glxinfo.c. > > 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")? Yeah. > 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. Hrm. glxinfo still wants to link against libglut; I guess this is just an artefact of the build system. > > 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. Okay, this sounds fine to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]