On Sat, Jul 14, 2007 at 10:20:24PM +0200, Cyril Brulebois wrote: > Peter Chubb <[EMAIL PROTECTED]> (15/05/2007): > > Package: skyeye > > Version: 1.2.1-2 > > Severity: grave
> > On a fresh x86 installation, trying to run skyeye gives: > > skyeye: error while loading shared libraries: libbfd-2.17.so: cannot > > open shared object file: No such file or directory > After a rebuild, it looks like this is gone. Although, I noticed this > during the build: > dpkg-shlibdeps: warning: unable to find dependency information for shared > library libbfd (soname 2.17.50.20070713, path libbfd-2.17.50.20070713.so, > dependency field Depends) > It looks to me that a binNMU might be sufficient, hence Cc-ing > debian-release. Except that a binNMU will still pick up a dependency on 'binutils', which is still wrong. I find four packages in the archive that are picking up a dependency on 'binutils' by way of shlibs: ggcov, nitpic, skyeye, and sysprof. nitpic needs libbfd-2.16.91.so, that's nice... ggcov, sysprof, and skyeye at least manage to have binary packages in stable that depend on the matching version of binutils. But all four packages are buggy, as is binutils for providing broken shlibs. The shlibs provided by binutils are effectively not supportable in a stable release; which means that until binutils has reasonable shlibs (perhaps using a virtual package name, the way apt does for its library?), packages should not be dynamically linking to libbfd. No binNMUs scheduled -- that would fix the current brokenness of the binary packages in unstable, but wouldn't fix the root RC bug. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
