Hi again, Raphael Hertzog wrote:
> That would be the wrong thing to check. We want to verify if it's a > ELF object and if not then we skip it. And we should not skip it silently > IMO as it was explicitly passed in a list of stuff to analyze. > > We already have the required Dpkg::Shlibs::Objdump::is_elf(). I went back to make this change but I decided I do not want it. It would have brought on two regressions: 1. dpkg-shlibdeps currently supports non-ELF files as long as objdump does. Of course all Debian architectures use ELF by default, but there are users for dpkg outside of Debian (fink on Mac OS X, for example). Can we assume that all users of dpkg-shlibdeps use ELF objects exclusively? If we can, dpkg-shlibdeps could be simplified a lot by using readelf instead of objdump. That’s something I would enjoy doing. 2. dpkg-shlibdeps currently complains if you pass it some random garbage. Maybe it would be nice to have a separate accept-anything mode so you can throw your entire debian/tmp at it. That’s not my itch. I was looking to ignore interpreted files because they are the only files other than object files that are supposed to be marked executable and placed in /usr/bin or /usr/lib/package. This is better than suppressing all errors because errors are useful. Meanwhile I do not want to break other people’s workflows. So I would be very interested in hearing concrete problems this imposes, so I can find a way to avoid breakage without unnecessary complication. Jonathan -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100421174754.ga23...@progeny.tock
