On Fri, 18 Jan 2008, Mark Brown wrote: > On Fri, Jan 18, 2008 at 09:45:17PM +0100, Raphael Hertzog wrote: > > > The provided symbols files do not match reality on all arches. It seems to > > me > > that you have to provide arch-specific symbols files that include either a > > 32bit version or a 64bit version depending on the case apparently. > > You mean like these? > > debian/zlib1g.symbols.arm > debian/zlib1g.symbols.armel
Indeed. Sorry, I haven't checked the source package. > On Fri, Jan 18, 2008 at 09:45:17PM +0100, Raphael Hertzog wrote: > > > [EMAIL PROTECTED] 1:1.1.4 > > + [EMAIL PROTECTED] 1:1.2.3.3.dfsg-9 > > [EMAIL PROTECTED] 1:1.1.2 > > These symbols are not in the symbols file because they shouldn't be > there on 64 bit cross builds; anything using them is buggy. Given this > I was perfectly happy with the default since the symbols files expressed > exactly what I wanted them to express in a very natural fashion. I'm sorry I don't understand. Why should they not be there and why can't they be hidden/removed if they are not wanted? Also if nobody is suppossed to link against them, and if you can't make them disappear, what about associating them to an unsatisfiable dependency for examples with entries like: libz.so.1 zlib1g #MINVER# | link-with-private-zlib-symbols [EMAIL PROTECTED] 1:1.1.4 [EMAIL PROTECTED] 1:1.2.3 1 [EMAIL PROTECTED] 1:1.1.2 I have another question: why does the lib64z1 package provide a symbols file that generates a dependency on "zlib1g" and not "lib64z1"? It looks like a bug to me given that the shlibs correctly indicates lib64z1. lib32z1 is also affected on 64 bit arches apparently. I suggest to remove the header line in zlib-base.symbols and create a zlib1g-base.symbols with the header line and with an include on zlib-base.symbols. Also remove the header line in zlib-(32|64).symbols they are not needed. Update all the zlib1g.symbols.arch files to include zlib1b-base.symbols instead and update the lib(32|64)z1.symbols with a correct header line. (The alternative is to override the header in lib(32|64)z1.symbols by adding the correct header line _after_ the #include if the include contains an unwanted header line). > If you're going to file bugs like this I would suggest removing the > support for this from dpkg-shlibdeps. Please, it was not meant as an attack. On the contrary, I'm quite happy that you're part of the few who tried the symbols mechanism quite early. We're still discovering what good practices are and that's why I submitted this bug and that's why I added the lintian check. I didn't expect that it was a deliberate choice of yours to not list symbols which are actually provided by the lib. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
