Hi Aurelien and Stephen, On Mon, May 04, 2020 at 12:00:28AM +0200, Aurelien Jarno wrote: > It's something we can fix. I found strange nobody notice so far. Does it > mean the bootstrap is done ignoring the build-dependencies?
Yes, I still ignore build-depends entirely. glibc depends on a specific version of the compiler and such dependencies are not compatible with cross compilation until we fix #666743 aka gcc-for-host. That bug has a patch, but nobody wants to review it and communication isn't working best on the issue either. If you really want to make a dent now, you need to do like src:linux does: Build-Depends: g++-9 <!cross>, g++-9-aarch64-linux-gnu [arm64] <cross>, g++-9-arm-linux-gnueabi [armel] <cross>, ... Do you want that? Doing so still means me hacking up the package during bootstrap, because I always force the compiler version regardless of whether glibc supports that. > Thanks for the detailed explanations. It looks to me that it's better to > add a different package. And while mtrace looks a good candidate to join > this package, I am not sure we can handle the transition easily. It > would mean that libc6-dev-bin need to depends on that new package at > least for one release cycle. And we actually don't want that for stage > 2, which means producing different packages for stage2... Let me point out that a transitional dependency is not a huge cost to reproducibility. Making the dependency optional to stage2 is reasonable. libc packages are not yet reproducible across stages. That's more of a vision. In diffoscope, such a dependency difference is very light. I agree with everything else you said around moving mtrace though. So judge it on its own knowing that it won't negatively impact bootstrap. When thinking about bootstrap, it helps to always think of any kind of transition as atomic (i.e. completed once started). It might be temporarily broken, but since you always rebuild everything from source, you can simply fix up anyth broken rdeps immediately. Helmut
