On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
> Also, for those who aren't aware, the new xorg packages now in
> unstable are also implicated in the C++ transition, because libGLU is
> implemented in C++.
Keyword: implemented.
All of GLU's interfaces are C, not C++, so "transitioning" libGLU is
ill-advised at best.
What I mean here is that no package should:
a. Have an exclusive dependency on libglu1-xorg
b. Have to wait for libglu1-xorg to enter etch
c. Be trainsitioned because of libglu1-xorg
libglu1-xorg reads:
Replaces: libglu1c2, libglu1, libutahglx1, mesag3 (<< 5.0.0-1),
xlibmesa3 (<< 4.2.1-5), xlibmesa3-glu, xlibmesa-glu
Provides: libglu1c2
the provides is there in order to allow for other packages to provide
libGLU, which is nice, thank you so much, but broken.
Are you aware of a situation that needs this or are you doing this
"just in case"? I have tried several GLU-using C++ and libraries
compiled with g++ 3.3 with the binary provided by libglu1-xorg and they
are working fine. I have also compiled programs against libglu1-xorg's
libGLU and they run fine with other libGLUs compiled with gcc 3.3.
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
