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

Re: Procedure reminders on updating a lib package for a C++ ABI change

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

Reply to: