On Sun, Feb 28, 2021 at 03:23:47PM +0100, Nicolas Boulenguez wrote: > Can you describe the scenarios you want to avoid? The binutils-* are > quite different from each other.
Some binutils bug is discovered. Once understood, Matthias is usually quick at uploading a fixed binutils. However binutils-* are not uploaded at the same frequency and still exhibit the bug. The bug is usually closed and it takes a while to figure that we still have a copy of it in the archive, because some binutils-* wasn't rebuilt. Reproducibility is another issue. If you natively build an or1k package and compare it to a cross built one, the cross build usually does not reproduce the native build, because the cross toolchains are outdated with respect to the native toolchains. A solution to both would be regularly uploading the binutils wrapper packages. However, that's not what is happening in practice. The second best solution is reducing their number as much as possible. Doing so makes updating them all remotely feasible. > Small wrappers like binutils-{bpf,or1k-elf,...} are Built-Using: > binutils-source. As long as they build against latest binutils, there > is no difference with building them from binutils.dsc. But if/when > they FTBFS, the failure does not involve unrelated maintainers. In practice, the wrapper packages are always outdated and for or1k, you wouldn't expect frequent FTBFS. > On the other hand, some binutils-* packages keep an old copy the > binutils source tarball, for example because the patches from the > hardware vendor have not been rebased yet. The Debian maintainers > know very well that this is not ideal, but in this case sharing the > source package is simply not an option. For more exotic binutils - in particular those needing patches or older versions - using a separate source package is reasonable. or1k does not seem to fall into that category. All we need to do is change one line in the binutils source package and be done. Helmut