Re: Debian policy update (3.8.4.0)
Simon McVittie <smcv@debian.org> writes:
> 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?
I'm just stating what is required for a package to conform to
Multi-Arch: same. In cases where you feel policy disagrees or support is
still unclear that means the package can not be Multi-Arch: same yet.
> * the real runtime library (libdbus-1.so.3.4.0) and the SONAME symlink
> (libdbus-1.so.3) SHOULD move to the multiarch directory
MUST for Multi-Arch: same.
> * binaries appropriate for ${libexecdir} SHOULD move to a subdirectory of the
> multiarch directory
MUST for Multi-Arch: same.
> * the development symlink (libdbus-1.so) and the static library (libdbus-1.a)
> MAY move to the multiarch directory
MUST for Multi-Arch: same. BUT -dev packages need not be multiarchified
yet. Do test and upload to experimental and such when playing with this.
> * 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)
MUST for Multi-Arch: same. And gtk-2.0 is one of the important libs that
people need multiarchified. Having a multiarch libgtk but no multiarch
plugins will make little sense.
> * .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]
Or at least is untested. Given the release goal it seems pointless to
care. But as long as you have an .la file and that must be in /usr/lib
the -dev package can not be Multi-Arch: same, which is not a problem.
> * 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]
I disagree there.
| 9.1.1 File System Structure
|...
| Applications may also use a single subdirectory under
| /usr/lib/triplet.
I believe that means anything that is allowed in /usr/lib/package/ is
also allowed in /usr/lib/triplet/package/.
MUST for Multi-Arch: same. BUT -dev need not be multiarchified yet.
> * 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]
Again I disagree. I don't think policy is blocking here. The problem is
pkg-config supporting it. Fix for pkg-config pending? (see other mail in
this thread)
MUST for Multi-Arch: same. BUT -dev need not be multiarchified yet.
> 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.
With the exception of .la and .pc files I do not think that moving the
files is harmfull nor that policy forbids it (see 9.1.1). And they need
to move there eventually anyway (or to /usr/include/triplet/). Further
the files move there naturally when you set --libdir and one must set
--libdir=/usr/lib/$(DEB_HOST_GNU_TYPE) for plugins.
Overall it makes no sense not to move the files with the exception of
*.la and *.pc files. Setting --libdir will set the correct paths in *.la
and *.pc files too and they themself can be moved back safely. Patching
configure.ac would just be wasted in the long run. If policy forbids
this then policy needs to be changed instead of patching thousands of
sources.
> Regards,
> Simon
MfG
Goswin
Reply to: