[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



Reply to: