On Sat, Nov 02, 2002 at 01:38:17PM -0500, Lukas Geyer wrote:
> Matijs van Zuijlen <Matijs.van.Zuijlen@xs4all.nl> writes:
>
> > On Thu, Oct 31, 2002 at 02:22:33PM -0500, Lukas Geyer wrote:
> > >
> > > The API issue is even more hairy. The header of libutahglx-dev claims
> > > to be MESA compliant, version >= 3.2. However, it does not provide
> > > /usr/include/GL/osmesa.h which is in MESA since 1.2.4 if I can believe
> > > the MESA docs. The source package of libutahglx-dev contains that MESA
> > > code but it is not built. I am not interested in this package, but if
> > > someone takes it over, _please_ check that the package really provides
> > > what it claims to. Otherwise it will cause FTBFS and thus
> > > release-critical bugs on other packages, like #142129.
> >
> > This bug complains about a missing osmesa.h. However, this file is not
> > even in xlibmesa-dev, but only in xlibosmesa-dev, the development
> > package for the off-screen rendering library. So it seems geomview
> > should build-depend on that, and depend on xlibosmesa3 as well.
>
> The reason that xlibosmesa-dev does not cause build failures is that
^^^^^^^^^^^^^^
I think you meant xlibmesa-dev?
> it does not #define MESA in /usr/include/GL/gl.h. geomview is
> perfectly able to compile without osmesa.h, but _not_ if the header
> defines the preprocessor symbol MESA. In my understanding, off-screen
> rendering is part of MESA, and defining MESA would assure that it is
> available. However, if you have some documentation that this is the
> wrong interpretation, please provide it and I will close the bug.
Ok, I see your point. So it seems the xlibmesa-dev package avoids this
problem by not actually claiming to be MESA compliant. For now, I will
avoid the averse effects of this bug by having libutahglx-dev not even
claim to provide libgl-dev.
--
Matijs van Zuijlen
... designed to fill holes or cracks of not more than two cubic vims.
-- Robert Sheckley, Untouched by Human Hands
Attachment:
pgp_lePlVRnF6.pgp
Description: PGP signature