Hi Florian, Thanks for doing all of this, since it was rather manual work for me.
Afaik, there are 3 kind of problems with zlib: - It's build-depending zlib, but linking staticly - It has it's own copy of zlib, and links staticly to it - It has it's own copy of the zlib package (ia32-libs, amd64-libs) And I have no idea which of those problems your automated tests found, or how you did it exactly. How I would do it is check all binaries and libs to: - Contains zlib, like staticly linked. I guess clamscan did that somehow? Does it find all version, compiled with different compiler version and options? I have no good way of finding this. - Doesn't not have a dedepency on the zlib (objdump -p file | grep NEEDED) My main problem has been the detection of the first, and I basicly was only able to find those that are completely linked staticly, and I was doing this by checking the build logs. An alternative approach I had in mind was checking all sources to contain the zlib source internaly. As part of Q&A we want to get rid of those and some other libraries and want to make sure those are dynamicly linked to the version in debian. It would be nice if we could have a list of all packages like this. You will of course have to take packages using tar in tar into account. Are you willing to those tests for some of those other packages people tend to include which really shouldn't be included? I had things like gettext, boost, icu, readline, db* in mind. Anybody else know of any libraries we should check? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
