Re: Bug#636383: debian-policy: 10.2 and others: private libraries may also be multi-arch-ified

[Simon McVittie <smcv@debian.org>]

On Sat, 03 Dec 2011 at 15:17:29 +0900, Charles Plessy wrote:
> We could resolve this by either disallowing to use
> <file>/usr/lib/<var>triplet</var></file>, or by explaining that the
> subdirectory must be private to the package or to a set of collaborating
> packages, as the non-public libraries themselves.

I think private libraries in [/usr[/local]]/lib/TRIPLET/subdir should
certainly be allowed:

* it's what will naturally happen if an autotools package with plugins or
  private libraries is converted to multiarch in the obvious way
  (./configure --libdir='$prefix/TRIPLET')

* it's the only sensible way to allow installing instances of the same module
  for, for instance, 32- and 64-bit Gtk+ simultaneously

* it's existing practice: at least ALSA, Avahi, colord, cuneiform, CUPS,
  D-Bus, DRI, gconv, Gdk, GLib, GStreamer, Gtk+, Gutenprint, GVFS, Java (JNI),
  Kerberos, eglibc, fakeroot, V4L, NSS, ODBC, OpenSSL, Pango, PKCS11,
  pkg-config, PolicyKit, refdbg, SANE, SASL, vdpau and PAM do this already
  (those are the ones on my laptop, there are almost certainly others...)

Regards,
    S