Re: mesag3 <-> xlibmesa-gl / libgl1-mesa-dri <-> xlibmesa-dri / libglu1-mesa <-> libglu1-xorg
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.
Reply to: