[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian policy update (

Steve Langasek wrote:
> On Mon, Feb 01, 2010 at 11:17:19PM +0000, Simon McVittie wrote:
> > In the meantime, is there consensus that shuffling the development files into
> > /usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
> > appropriate for -dev packages where all the arch-dependent files are in
> > arch-specific directories? I'd rather not break future work if -dev packages
> > aren't really settled yet.
> The policy exception is currently not written to permit this.  Please don't
> upload packages to the archive that violate policy.

I'd interpreted Policy §9.1.1 (3) as allowing anything that would normally be
installed to [/usr]/lib to be installed to [/usr]/lib/TRIPLET, but looking
at it again, it does indeed specify "object files, internal binaries, and
libraries". Am I right in thinking that this means the following?

* the real runtime library (libdbus-1.so.3.4.0) and the SONAME symlink
  (libdbus-1.so.3) SHOULD move to the multiarch directory

* binaries appropriate for ${libexecdir} SHOULD move to a subdirectory of the
  multiarch directory

* the development symlink (libdbus-1.so) and the static library (libdbus-1.a)
  MAY move to the multiarch directory

* plugins (e.g. /usr/lib/gtk-2.0/modules) MAY move to a subdirectory of the
  multiarch directory (but this will need coordination between the maintainers
  of the plugin loader and the plugins)

* .la files MUST NOT move to a subdirectory of the multiarch directory;
  http://wiki.debian.org/ReleaseGoals/LAFileRemoval will eventually make this 
  [rationale: earlier in the thread, Goswin explained that this doesn't work]

* architecture-specific header files currently found in /usr/lib (on my
  system: D-Bus, GLib, Gtk, ejabberd) MUST NOT move to a multiarch directory
  [rationale: Policy doesn't yet say they can]

* miscellaneous architecture-specific non-library data (pkg-config .pc files)
  MUST NOT move to a multiarch directory
  [rationale: Policy doesn't yet say they can]

In each case where I'm wrong, could you please explain whether putting those
files in multiarch directories is currently forbidden, discouraged, encouraged
or recommended?

For autotools packages that hard-code paths, usually because they have plugins
(gtk-2.0 is a good example), the only reliable way to divert the runtime
library into /usr/lib seems to be to use `./configure --libdir=TRIPLET`,
which means that files destined for any directory of the form ${libdir}/foo
will get diverted too, even if current Policy forbids this. Should maintainers
be using --libdir and then moving forbidden files (e.g. pkg-config files)
back to the arch-neutral location, or encouraging upstreams to provide
more --whateverdir switches, or what?

A concrete example: if I understand correctly, Goswin suggests I use --libdir
on dbus, to make it more exemplary, and in particular not misleading for
maintainers of packages that do hard-code paths. However, I would then need
to move the .pc file and the arch-specific header back out of the multiarch
directory to comply with what you said, editing the .pc file to have the
right path for the arch-specific header in the process, unless I patch
configure.ac to add some sort of --archincludedir option, autoreconf, and
use that option.


Reply to: