On Sat, Jul 16, 2005 at 12:00:12PM -0600, Marcelo E. Magallon wrote: > 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. Oh, ugh. I think the XSF was essentially following Ubuntu's lead here; no one realized, or thought to check, that the C++ bits weren't exported as part of the ABI. David, do you want me to put together a patch that updates the Provides/Conflicts of libglu1-xorg appropriately? (Might as well keep the name change now that it's been done, I think.) -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature