[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 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")?


> 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: