FR: Support for multiarch shared library paths

[jinnatar]

Why

The software I'm looking to switch over to cargo-deb (https://github.com/kanidm/kanidm) already has an existing deb pipeline, which is cumbersome. However it currently drops dynamic libraries into locations defined by the multiarch triplet, for example:

• ./lib/x86_64-linux-gnu/libnss_kanidm.so.2
• ./lib/x86_64-linux-gnu/security/pam_kanidm.so

Especially the latter seems to be a required path as that's the one where a modern Debian install with multiarch will look for PAM modules without extra trickery.

The problem

• If I want to support multiple target architectures I should not hardcode the triplet in the cargo-deb metadata.
• The only way I see around this is separate variants that hardcode a different triplet. This gets very unwieldy though quite quickly in a complex project.

Proposed solution(s)

• Perhaps an added argument for assets could alleviate this, to allow enabling a multiarch prefix per asset. Manual yes, but full control.
• Alternatively a top/variant level option to turn on multiarch triplets for all shared libraries. This would match current Debian recommendations as best I can tell: https://wiki.debian.org/Multiarch/Implementation#What_does_the_end_result_look_like.3F

[kingosticks]

I have what I think is a similar problem, where my asset needs to be installed in a location based on the the arch triple. My solution so far has been to use a variable with a string interpolation pre-processing step. Hacky but it works.

I'm actually using the result of pkg-config to find the directory rather than attempt to hard-code it. I don't know if the proposed solutions would provide quite the same flexibility as my hack allows, but they'd probably suffice for me.

[kingosticks]

Oh, apologies, I forgot someone (not me!) already posted this as #35

[jinnatar]

Thanks for finding that, I'd missed it while searching. What seems to have changed since then is that multiarch is in real world use, outside of cross-compile. But for now I'll try your hack, seems perhaps easier on other devs than variants.

Edit: The annoying part about post-processing in the multiarch path is that it's annoying to resolve a package name to it's Cargo.toml. So I guess I'll stick with variants and hoping no one runs without a variant and gets a broken deb.

[kornelski]

I think it makes sense, and could be supported.