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
