[debhelper-devel] Bug#759812: Make the multiarch tuple available in helpers

Christian Kastner debian at kvr.at
Sat Aug 30 16:54:03 UTC 2014


Package: debhelper
Version: 9.20140817
Severity: wishlist
Tags: patch

With multiarch, some use cases which would traditionally be solved
through the static *.dirs, *.install, and *.link files now require
hackery in debian/rules instead, as some of the operations need the
build-time multiarch tuple.

It would be great if these files would support a substitution or
placeholder for the multiarch tuple so that we can go back to the
traditional approach even for multiarch packages.


Example #1
==========

A library package with a custom Makefile that installs everything to
$(DESTDIR), and in particular the shared library to a hard-coded
$(DESTDIR)/usr/lib/.

Before multi-arch, this was not an issue. I would just have created
simple one-line debian/libfooX.install files, and be done with it. Now,
I have to query DEB_HOST_MULTIARCH in debian/rules, override dh_install,
and move stuff around manually. Given the long path names involved, this
is really clutters up things.

Example #2
==========

An essential library package using autoconf.

The FHS specifies that the essential library should go into /lib/, but
development files (eg: .so symlink, pkgconfig files) must go into
/usr/lib/. This, too, requires a lot of manual moving and symlinking
where otherwise one-line *.{dirs,install,link} files would have sufficed.


Proposed Solution
=================

The attached patch extends dh_installdirs, dh_install, and dh_link such
that in v10 mode, the literal string :multiarch: is substituted with the
appropriate multiarch tuple during their operation.

Coming back to example #1, this should then work (and make debian/rules
hackery unnecessary):

  [ debian/libfooX.install ]
  usr/lib/*.so.*    usr/lib/:multiarch:/

The real added value is in the more complex cases, though.


Possible Issues
===============

The substitution is currently applied not only to debian/package.*
files, but to direct invocations of the dh_* helpers as well. I don't
know if this is a problem.

There might be a better alternative to the choice of :multiarch: as
substitution string, but to avoid conflicts, it should probably not
include symbols with a special meaning within debian/rules.

The dh_link extension is not as useful as the others because it does not
support wildcards are not supported. For example, in the -dev package, I
cannot symlink the .so to the .so.X.Y via .so.*.*

I haven't looked into the translation stuff.

I'm not aware of any use cases for it, but theoretically the same
approach could be applied to other DEB_*_ variables, in which case a
substitution such as :host:multarch: might be better.

Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-the-multiarch-tuple-available-in-some-helpers.patch
Type: text/x-patch
Size: 4525 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debhelper-devel/attachments/20140830/71080447/attachment-0001.bin>


More information about the debhelper-devel mailing list