Hi, Quoting Simon McVittie (2024-08-01 11:22:39) > > I recently encountered the following packages that would fail to install > > their Build-Depends due to choosing a host architecture Python interpreter > > and failing its postinst: [29 packages] > > That's not actually all that many. I wonder whether it would be pragmatic > to add python3:native to their B-D and move on? > > Or teach crossqa or sbuild to always --add-depends=python3:native when > cross-building? In the worst case scenario that's adding python3 when > it isn't actually needed, but increasingly many packages use Meson which > pulls in python3 anyway, so maybe that's not so bad?
no, this would be very wrong. I think it is really important to keep the set of build dependencies that gets installed minimal. I was putting quite a bit of work to getting the set of packages in the buildd variant reduced to just essenital plus build-essential plus apt. I'd very much dislike adding python or other culprits to the list. Even when we say "but it's just for cross compiling" that makes it even worse in my eyes. We should *reduce* the special-casing for cross compilation and not add to it. But I might be persuaded to extend /usr/lib/apt/solvers/sbuild-cross-resolver to carry an allow-list of packages which need to be installed in their native variant. That script already takes care to install M-A:foreign packages in their native architecture. Maybe more packages just need to be added to this special handling? Thanks! cheers, josch
signature.asc
Description: signature
