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? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
