Packages that have a plugin architecture, like glib2.0 and gdk-pixbuf,
often want to know the multiarch tuple in their maintainer scripts so
that they can enumerate plugins in a multiarch-qualified directory or
run multiarch-qualified helper programs.

At the moment, dpkg provides DPKG_MAINTSCRIPT_PACKAGE and
DPKG_MAINTSCRIPT_ARCH in maintainer scripts' enviroment, but packages
that need to know the multiarch tuple have to generate their maintainer
scripts from a template: for example, glib2.0 and gdk-pixbuf have a
.postinst.in template containing #MULTIARCH#, which gets substituted by
the package build.

It would be simpler for packages in this situation if dpkg provided
something like DPKG_MAINTSCRIPT_MULTIARCH in the environment.

    smcv

Hi,

Already mentioned this to Simon on IRC, but I figured it would make
sense to say it on the bug as well.

Since debhelper/12.5(.1), dh_installdeb provides the Multi-arch tuple
for you via the #DEB_HOST_MULTIARCH# token in your hand-written
maintainer scripts.  You can also reference other
DEB_{HOST,BUILD,TARGET} variables as well as environment variables
without any custom substitution process (see man dh_installdeb for
details).  I hope it will cover your need for having ".in" maintainer
scripts and your custom substitution.

(This is not a statement on whether dpkg should or should not provide
this variable at runtime - just a remark that dh_installdeb might solve
the use-case already)

Thanks,
~Niels

Hi!

Sorry, didn't mention anything at the time because Niels reply seemed
like a better answer to this problem, that was already supported.

In any case, while this might be nice to have, it requires pretty much
reimplementing parts of dpkg-architecture in C to be usable from
libdpkg or dpkg itself, because we'd need to map the .deb arch into
the multiarch triplet, which we should not be hardcoding internally.

This has crossed my mind doing, and I think I started work in that
direction, but it has also not seemed a very urgent thing to do TBH.

Thanks,
Guillem