Your message dated Sun, 11 Aug 2013 11:53:59 +0200 with message-id <[email protected]> and subject line Re: Bug#707128: Actually warrant documented "--ignore-missing-info" has caused the Debian Bug report #707128, regarding Actually warrant documented "--ignore-missing-info" to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 707128: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707128 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dpkg-dev Version: 1.16.10 Severity: normal File: /usr/bin/dpkg-shlibdeps now the same "couldn't find library" message could be warning or error, e.g. dpkg-shlibdeps: warning: couldn't find library libmat.so needed by debian/matlab-psychtoolbox-3-nonfree/usr/lib/matlab/site/psychtoolbox-3/WaitSecs.mexa64 (ELF format: 'elf64-x86-64'; RPATH: '') dpkg-shlibdeps: error: couldn't find library libeyelink_core-1.9.so.58 needed by debian/matlab-psychtoolbox-3-nonfree/usr/lib/matlab/site/psychtoolbox-3/Eyelink.mexa64 (ELF format: 'elf64-x86-64'; RPATH: '') N.B. this is for some non-free package which relies on users having a shared library provided manually and in case of the error the whole run of dpkg-shlibdeps fails without generating substvars. The situation persists even if I use documented: --ignore-missing-info Do not fail if dependency information can't be found for a shared library. Usage of this option is discouraged, all libraries should provide dependency information (either with shlibs files, or with symbols files) even if they are not yet used by other packages. which from the description sounds precisely what I need, but in the code is not influencing decision to exit with error upon $error_count. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 'stable'), (100, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii base-files 7.1 ii binutils 2.22-8 ii bzip2 1.0.6-4 ii libdpkg-perl 1.16.10 ii make 3.81-8.2 ii patch 2.6.1-3 ii xz-utils 5.1.1alpha+20120614-2 Versions of packages dpkg-dev recommends: ii build-essential 11.5 ii fakeroot 1.18.4-2 ii gcc [c-compiler] 4:4.7.2-1 ii gcc-4.4 [c-compiler] 4.4.7-2 ii gcc-4.5 [c-compiler] 4.5.3-12 ii gcc-4.6 [c-compiler] 4.6.3-14 ii gcc-4.7 [c-compiler] 4.7.2-5 ii gnupg 1.4.12-7 ii gpgv 1.4.12-7 ii libalgorithm-merge-perl 0.08-2 Versions of packages dpkg-dev suggests: ii debian-keyring 2012.11.15 -- no debconf information
--- End Message ---
--- Begin Message ---Hi! On Tue, 2013-05-07 at 15:47:36 -0400, Yaroslav Halchenko wrote: > On Tue, 07 May 2013, Guillem Jover wrote: > > > ;) well -- as I have mentioned, it is a non-free package (not even in > > > Debian's non-free yet) which provides pre-built binary blobs > > > (extensions), which on their own are redistributable, but that library > > > is not. So it is upstream who builds/links against them -- I was just > > > wrapping them into a convenience non-free package. > > > Hmm, ok I see. This means installing the package will not produce a > > working program, I've to question the point of packaging this at all? > > Why not an installer-style package instead? > > installer-style package for the package in question would not resolve > any problem -- that was the point of the exercise to take advantage of > dpkg-shlibdeps to collect dependencies. Installer package for the > library leading to error might be unfeasible (e.g. commercial-for-money > and N/A while building the package). Ok, pondered about this a bit, and the right solution to this is to package the non-redistributable non-free packages, if you want to make those available to others then you'd need an installer-style package or just some scripts to wrap the non-free bits into few binary packages. With these, you can properly declare on your plugins packages Build-Depends on the -dev package and get correct depedencies for the shared library. This will also make sure you have the correct shared library in case the SONAME got bumped, for example. > > > > generating pretty broken packages, for no apparent good reason. Given > > > > this I'm inclined to close the bug report if no convincing > > > > counter-arguments are put forward. > > > I agree that it might lead to completely broken packages and generally > > > should not be used. But in some cases (like mine) for non-free packages > > > I see this option being useful. > > Yes, it kind of “makes sense” it that case, but I'm not sure I'm happy > > supporting that case (see the above question). I'm open to further > > pondering about it though. > > and I understand your hesitance -- such use-cases are rare, and not per > se toward solidification of Debian infrastructure within available > suites (i.e. main/contrib/non-free). This might come useful though for > internal/commercial use-cases like the one I have at hands. Given the above, I think the right answer is through packaging, not by making it easier to subvert the packaging system. :) Thus closing. Thanks, Guillem
--- End Message ---
