Output dynamic libraries in architecture library path

[3nprob]

[2022-06-17T04:55:18Z DEBUG cargo_deb] stripping /home/user/helloworld/target/x86_64-unknown-linux-gnu/release/libfoo.so with strip
info: Stripped '/home/user/helloworld/target/x86_64-unknown-linux-gnu/release/libfoo.so'
info: /home/user/helloworld/target/x86_64-unknown-linux-gnu/release/libfoo.so -> usr/lib/libfoo.so (7MB)
info: - -> usr/share/doc/helloworld/copyright (246B)

This makes the library end up in usr/lib/libfoo.so, where it's expected in e.g. usr/lib/x86_64-linux-gnu/libfoo.so.

Cf https://github.com/kornelski/cargo-deb/blob/0943fe841b7ccb5b8b1eca7bdce4e635508bc8f1/src/manifest.rs#L856

Perhaps something like guess_host_triple can be adopted (I guess such an implementation should be contained here rather than relying on a third-party crate, though?).

[kornelski]

I think this path is correct. usr/lib/x86_64-linux-gnu/ is only a sysroot for cross-compilers. On the target system these libraries are in /usr/lib/. Cross-compilation is meant for running the executable natively on the target system, not under emulation on the host system.

[3nprob]

So what's prompting this report is ad-hoc packaging gst-plugins-rs.

https://github.com/mopidy/mopidy-spotify/issues/110#issuecomment-1158336802

Take a look at https://packages.debian.org/buster/amd64/gstreamer1.0-plugins-bad/filelist for example.

Granted I'm not 100% confident in the best practices and idioms here.

[3nprob]

An alternative approach would be to enable simple templating in assets, for example allowing to specify a target_dir of usr/lib/$deb_target/foo or similar, to allow overriding it in case this is indeed an exceptional case.

What'd your stance be on that if a PR would be incoming at some point? :)

[kornelski]

gstreamer wants libraries in a custom directory with /gstreamer-1.0/. That's their choice, different from the default convention.

Supporting variables in paths sounds like a good idea.