On Thu, Jun 07, 2007 at 09:05:23AM +0200, Raphael Hertzog wrote: > On Wed, 06 Jun 2007, Steve Langasek wrote: > > > Can you expand? I don't see at all how libgl would "benefit" from this new > > > approach. The current shlibs is already very lax and non-versioned.
> > Yes, and that's the problem: I know the libgl shlibs to have been wrong in > > certain corner cases involving uncommon symbols (whether those are > > implementors adding their own extensions, or failing to implement the > > standard, or just exposing symbols in the lib that aren't part of the API in > > the headers, I don't know). > And how would the new system help ? > By default, it would list all existing symbols in the symbols file of each > package and it wouldn't detect any failure. > Do you expect the maintainer to mark some symbols as "private" which in > turn sould lead to an error in the dpkg-shlibdeps run for an application > using it? No, but I expect the maintainer to mark them as requiring a dependency on, e.g., nvidia-glx instead of on xlibmesa-gl | libgl1, or on libgl1-mesa-glx | libgl1-mesa-swx11 | libgl1-mesa-glide3 instead of on libgl1-mesa-glx | libgl1. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
