Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building

[Niels Thykier]

Helmut Grohne:
> Hi Simon and Niels,
> 
> (fixed Cc address for architecture-properties maintainers)
> 
> On Thu, Aug 01, 2024 at 05:26:04PM +0100, Simon McVittie wrote:
>> [...]
> 
> I talked to Niels off list and he was vaguely positive about riding on
> architecture-properties. He had some concerns about the bus factor that
> this work might impose on architecture-properties. Guillem also
> indicated that he wants to give feedback though not right now.
> 
> To me this is sufficient to prototype an implementation. I'm attaching a
> patch for architecture-properties that hopefully gets most of the
> details right (thanks to Simon's design feedback). If you prefer
> reviewing it on salsa, go
> https://salsa.debian.org/debian/architecture-properties/-/merge_requests/1
> 
> I request that we give people at least one week to reply before
> uploading this. I appreciate feedback from Niels as to how acceptable he
> finds this contribution.

I think I am good to go on this one. I would rely on someone else to 
keep up with the "hacks" required to detect emulations if the current 
check stops working and I would not use my self directly, so the tests 
mentioned below would be relevant or we do consumer based testing.

Those are the limitations I currently see. The code looks like it would 
be relatively stable and small enough that I can throw it directly at 
the C compiler maintainers if it ever ICEs or miscompiles.

> [...]
> 
> Writing tests is a bit non-trivial. Whilst Ubuntu has pioneered an
> autopkgtest extension for cross architecture testing, this does not seem
> to be available in Debian. Testing the native case is rather boring in
> my view. As for manual testing, I verified that :amd64 (natively), :i386
> (without installing qemu), and :armhf (qemu) work as expected on amd64.
> 

It would be boring to test the native flow, but it would still assert 
that the code minimally works. Therefore, I think we should have that 
test case. It would at the very least catch miscompiles where the 
c-program just SEGVs due to a miscompile.

For the non-native case, I think we could emulate that by playing with 
PATH and use that to mock `readlink` into an `echo /usr/bin/qemu` if we 
wanted to test the detection. I think that could also be used to trigger 
at least one of the error cases by having the mocked `readlink` return 
non-zero?

If we could get proper non-native tests as well, that would surely be 
better.

> In the event that dpkg gains the Provides suggested by Simon, we can
> delete both native-architecture and native-architecture-is.
> 
> Helmut

Sounds good to me.

Best regards,
Niels