[Pkg-openssl-devel] Bug#689093: libssl-dev is not Multi-Arch compatible

[Colin Watson]

block 689093 by 696390
thanks

On Thu, Dec 20, 2012 at 12:37:42AM +0100, Kurt Roeckx wrote:
> On Wed, Dec 19, 2012 at 01:16:16PM +0000, Colin Watson wrote:
> > This test (which I ran against current unstable) behaves *much* better.
> > Out of 413 packages, 402 built cleanly.  Two packages (eucalyptus and
> > freebsd-utils) were skipped because my test was on i386 and they don't
> > build there.  chromium-browser failed to unpack for some odd reason,
> > unrelated to OpenSSL.  Of the remaining eight failures:
> 
> Can you also verify that for those 402 that it has at least 1
> binary package depending on libssl1?

Thanks for suggesting this.  Some don't:

  389-ds-base aeskulap apcupsd asio autofs chntpw cmtk dicomscope eagle
  fwbuilder gambas3 gnome-commander gst-plugins-bad1.0 guymager
  handlersocket havp htcheck ifstat inspircd isc-dhcp iscsitarget
  kde4libs kdesvn libapache-mod-log-sql libfprint libgwenhywfar
  libyahoo2 mcabber mysql++ ntp openclonk opensaml2 openswan pam-mysql
  postgis postgresql-8.4 pygresql qpid-cpp qt4-x11 quassel quota racket
  rhash shibboleth-sp2 ssldump subcommander telepathy-rakia valknut
  vdr-plugin-live vidalia vmtk wzdftpd

I ran 'grep-aptavail -XFSource:Package "$x" | grep libssl1' on each of
these.  Most are false positives in that they don't have any libssl
dependencies in unstable either: I guess they're indirect dependencies,
redundant build-dependencies, or build-dependencies for build tools that
don't actually end up in the package.  rhash has a Recommends instead of
a Depends.

Looking through the logs manually as an extra sanity-check, the
following packages don't appear to even try to link against libssl or
libcrypto directly, and none of them observably fail to detect OpenSSL
(some don't seem to try at all; some try but then use something else
such as GnuTLS instead; a few seem to use the headers but rely on
something else for indirect linkage; some obscure their link lines so
it's hard to tell but seems harmless):

  aeskulap apcupsd autofs chntpw cmtk eagle fwbuilder gambas3
  gnome-commander gst-plugins-bad1.0 guymager handlersocket havp htcheck
  ifstat inspircd isc-dhcp iscsitarget kde4libs kdesvn
  libapache-mod-log-sql mcabber mysql++ openclonk opensaml2 openswan
  pam-mysql postgis postgresql-8.4 pygresql quassel quota racket
  shibboleth-sp2 subcommander telepathy-rakia valknut vdr-plugin-live
  vidalia vmtk wzdftpd

The following use -lssl or -lcrypto in link lines but don't end up with
dependencies on libssl1.0.0 (so presumably indirect linkage or unshipped
binaries):

  389-ds-base asio dicomscope libfprint libyahoo2 qpid-cpp

qt4-x11 uses the OpenSSL headers, apparently successfully, but relies on
run-time linking.

libgwenhywfar and ssldump already fail to detect OpenSSL, but those are
due to buggy library tests and have nothing to do with headers.

The one case that's a real problem is ntp, which does indeed misbuild
because it fails to detect OpenSSL headers.  I've filed a bug for this
with a patch (#696390).

-- 
Colin Watson                                       [cjwatson at ubuntu.com]