Hi Colin, On Thu, Sep 12, 2019 at 01:06:15PM +0100, Colin Watson wrote: > Package: gcc-for-build > Version: 4.9.2-1~exp3 > Severity: minor > > The package description reads: > > Ensures that there is a gcc binary that can create executable build > architecture binaries. No provitions are made about the build architecture > besides being executable. > > "provitions" looks like a typo for "provisions", so at minimum this > should be corrected.
Thank you for your attention to detail. I concur in principle. That said, this package is supposed to be taken over, but we're not there yet. The basic plan is: 1. binutils-for-build done 2. gcc-X.Y-for-build produced by src:gcc-X.Y aka #666743 3. gcc-for-build produced by src:gcc-defaults (no bug yet) I don't thik it makes much sense to invest further work into this proof-of-concept package. > That said, I'm not sure that sentence entirely makes sense even after > fixing the typo: "provisions" doesn't feel like quite the right word, > and the structure of the sentence implies that the build architecture is > executable, which is nonsensical. I think this sentence could use a > rewrite by somebody who understands what it was intended to mean. For one thing, compare with binutils-for-build. If that description also has issues, it is something we do want to improve, because it is meant to stay. We'll likely reuse the binutils-for-build wording when working up the stack. Then the idea about *-for-build packages is that it somehow (e.g. via dependencies) ensures that the relevant tools are available without an architecture prefix. The lack of a prefix means that a user should not make any assumption as to which architecture these tools work with except one: Code for that architecture can be executed in the setting where the *-for-build package is installed. Does this explanation make it any clearer? Helmut
