[Pkg-privacy-maintainers] Bug#902792: torsocks: does not support and fails catastrophically with muliarch

[Helmut Grohne]

On Wed, Mar 05, 2025 at 12:01:16AM +0100, Hefee wrote:
> Your patch will not work, as $LIB cannot tell what binary arch will be called 
> and do not know anything from multiarch. At least I read the documentation 
> like this.

The patch gets the core concept right and that's turning the package 
continaing libtorsocks.so M-A:same.

> But let's focus on the first step is to get torsocks multi-arch ready, so it 
> can be installed as multi-arch: same.

Yes, this aspect is part of any solution.

> That one is quite easy:
> * the lib is already installed at the correct place *check* 
> * all other files are arch independent *check*
> * the only file we need to care about is /usr/bin/torsocks.
> I use here the easy solution to move the binary to /usr/bin/$
> {MULTI_ARCH_TRIPPLET}-torsocks

That solution is fairly annoying to users as running torsocks no longer 
works. You now have to know what architecture your wrapped executable 
has. That may even be impossible if you wrap an amd64 shell that wants 
to execute an i386 executable.

The approach of triplet-prefixing is great for cross building as most of 
the tooling knows the triplet and it merely is a matter of propagating. 
It is not great at all for this use case.

> @helmut:

Consider mailing d-cross at l.d.o instead of me. Yeah, the question is not 
the core topic of the list, but it is close enough.

> But as a enduser I just want to use /usr/bin/torsocks, so I need a wrapper 
> script. I would use the "easy" solution ans just use the main architecture 
> (dpkg --print-architecture), but how to get the multi-arch-name for the main 
> architecture? 

The problem kinda is that there is no "right architecture". In my 
example of calling an amd64 shell that invokes a 32bit binary, neither 
is right.

> Or are you aware of any other solution to make use the correct torsocks script 
> /LD_PRELOAD?

I'm not sure I fully understand the fakeroot implementation, but the 
general approach also used by eatmydata seems to be installing the 
library directly into /usr/lib/<triplet> without a subdirectory and then 
listing the library name in LD_PRELOAD without the 
architecture-dependent leading directory components. fakeroot does not 
follow this path and instead adds a ld.so.conf.d snippet, but I don't 
think that's any better.

Helmut