Control: reassign -1 libc6-dev-i386 Control: affects -1 = src:gcc-14-cross Control: tags -1 + ftbfs
On Sat, Mar 15, 2025 at 05:45:15AM +0100, Matthias Klose wrote: > sudo apt build-dep gcc-14-cross > > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > Unsatisfied dependencies: > builddeps:gcc-14-cross : Depends: libc6-dev-amd64-cross (>= 2.37) but it is > not installable > libc6-dev-i386-amd64-cross : Depends: libc6-dev-amd64-cross (= > 2.40-4cross1) but it is not installable > libc6-dev-x32-amd64-cross : Depends: libc6-dev-amd64-cross (= 2.40-4cross1) > but it is not installable > Error: Unable to correct problems, you have held broken packages. Matthias and me discussed the matter on irc. The bug introducing the problem was #1092278 asking for libc6-dev-* to conflict with one another. Now the transformed libc6-dev-*-*-cross packages move e.g. /usr/lib32 to /usr/<triplet>/lib32 thereby resolving the underyling conflict in the transformed packages. Moreover, since the conflicts lack architecture qualifiers we get funky ones such as libc6-dev-amd64-amd64-cross that don't exist anywhere. Qualifying them is not a solution, because gcc-14-cross really wants both libc6-dev-x32-i386-cross and libc6-dev-x32-amd64-cross at the same time and while their package contents are coinstallable, the underlying glibc packages libc6-dev-x32:i386 and libc6-dev-x32:amd64 really are not coinstallable. It is the sysroot transformation that renders them coinstallable. Our discussion arrived at three ways to move forward from here and we did not reach any agreement here. 1. glibc should conditionally emit these Conflicts. When a particular environment variable is set by c-t-b, their emission is suppressed. 2. Someone (me?) develops a c-t-b patch that discards the conflicts in the repacking step as that also is the step that fixes coinstallability. 3. We revert those conflicts in trixie and retry with more time in forky. Matthias prefers 1. I object to 1 on reproducibility grounds and favour 3 given the state of discussion. Helmut
