On Sat, Jan 19, 2008 at 02:12:50PM +0100, Raphael Hertzog wrote: > 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?
They shouldn't be there because they are there to provide access to a 64 bit off_t on 32 bit architectures. When off_t is already 64 bit they are redundant. I could hide or remove them but I prefer to be extremely conservative in introducing any deviation from upstream behaviour so I'd rather have that change made upstream. > 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: I had assumed that you would complain about doing that too. > 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. Oh, bah humbug. I see - I hadn't realised that any attention was being paid to the package name in the header there. I had been under the impression for some reason that the package name for the dependency was generated from the package containing the symbol file. I remember looking at the header line, scratching my head about what the MINVER stuff was about and making a note to look at it when I worked out what it did but that never happened. I'll do yet another upload today or tomorrow. I have to say I find the specification of the package name in this way somewhat uncomfortable - with the 32/64 bit zlib varaints the toolchain must already have worked out which package contains the relevant libary in order to identify the relevant symbols flle. I'd be more comfortable if I were > > 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. Sure, it wasn't that I felt this was an attack. It was more that I had found the existing behaviour of the tools very useful (I especially like the fact that it will keep triggering warnings in the build) but that using this ended up generating high severity bug reports. > 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. The way I was looking at it the symbol files are a declaritive thing saying which symbols should be in the library and which minimum versions apply to each (this is why I don't autogenerate the lists of 64 and 32 bit cross architectures). That's why it made sense to ignore symbols that I didn't expect to find in the library. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
