Bug#1100544: glibc adds some conflicts letting gcc-14-cross ftbfs
On 2025-03-15 07:01, Helmut Grohne wrote:
> 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.
cross-toolchain-base has been an increasing burden in packaging glibc,
imposing too many development constraints and limiting changes that can
be made. Therefore my plan is to stop shipping the debian/ directory in
the glibc-source package starting with forky. cross-toolchain-base we'll
have to build the glibc from sources in its own way.
The toolchain being already frozen (since today), any change needs a
pre-approval, so I would rather go with option 1 to make the approval
easier.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: