Hi Helmut, On Tue Mar 18, 2025 at 7:48 PM CET, Helmut Grohne wrote:
I confirm. For the time being, you have no choice but to issue that dependency on libc6-i386 (which is the multilib package we might want to remove). However, you no longer need a multilib compiler, so that's one step closer.
Got it.
Longer term, moving the affected tests from build-time tests to autopkgtests may be an option.
I'd like to keep running the tests as build time as well; being consistent with what upstream does is amongst the reasons.
I'm not sure where we are regarding multiarch in autopkgtests, but Paride took some steps towards allowing libc6:i386 [amd64] as an autopkgtest dependency.
That'd be great! Also, it really wasn't obvious to me that I could use libc6:i386 instead of libc6-i386 on amd64 to get the desired dynamic loader. It is now, in retrospect. Using that package, to me, looks way more elegant than the multilib alternative.
As you haven't suggested me to do so, I guess it isn't possible to declare a build-dependency on a non-native package. Why? Is it because buildds only have apt sources configured for their native arch?
Keep in mind, that I am not sure whether we already have consensus on removing multilib. Whilst I am in favour of removing, I think consensus is more important.
I think that since we have multiarch and great cross-building in Debian, removing multilib makes sense. I also think, though, that we should do that only when multiarch can work wherever multilib currently does. For instance, it should be possible to depend on libc6:i386 wherever we can use libc6-i386 now (note: I don't actually know if this is already possible, I'm assuming it is not).
Thanks again for your help! Bye :)
Attachment:
signature.asc
Description: PGP signature