Re: Debian policy update (3.8.4.0)
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
irrelevant
[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.
Regards,
Simon
Reply to: