binutils: remove texinfo dependency

[Bo98]

The texinfo dependency tree is far too large for a critical component of Homebrew on older Linuxes.

It brings in the entire Python dependency tree and greatly increases the risk of including C++-only dependencies, which themselves require a modern GCC.

The dependency should also be completely unnecessary, but upstream's tarball is bugged.

[carlocab]

How useful even is gprofng? I'm a little keen on disabling it so we can also skip bison.

[Bo98]

No idea. Though at least bison is lighter.

texinfo dependency is indicative of a bug, since doc files should be pregenerated and we're not using autotools here.

[carlocab]

Does bison appear elsewhere in the Linux bootstrap dep tree? If not, we should just get rid of it.

[Bo98]

It does not.

[danielnachun]

So I guess the concern here is that these dependencies drag in a large tree for build dependencies? I have no strong feelings either way given that binutils is relocatable on Linux and will not typically need to be built outside of CI. However if these extra dependencies create problems in terms of dependency trees they should obviously be dropped.

[Bo98]

Yeah, texinfo should also never really be required if upstream had a functional tarball. I'll probably submit a patch upstream at some point.

For the record:

`brew deps --tree texinfo`

texinfo
├── ncurses
│   ├── pkg-config
│   └── gpatch
├── perl
│   ├── berkeley-db
│   │   └── [email protected]
│   │       └── ca-certificates
│   ├── gdbm
│   └── expat
└── gettext
    ├── libxml2
    │   ├── [email protected]
    │   │   ├── pkg-config
    │   │   ├── gdbm
    │   │   ├── mpdecimal
    │   │   ├── [email protected]
    │   │   │   └── ca-certificates
    │   │   ├── readline
    │   │   │   └── ncurses
    │   │   │       ├── pkg-config
    │   │   │       └── gpatch
    │   │   ├── sqlite
    │   │   │   ├── readline
    │   │   │   │   └── ncurses
    │   │   │   │       ├── pkg-config
    │   │   │   │       └── gpatch
    │   │   │   └── zlib
    │   │   ├── xz
    │   │   ├── bzip2
    │   │   ├── expat
    │   │   ├── libffi
    │   │   ├── libxcrypt
    │   │   ├── ncurses
    │   │   │   ├── pkg-config
    │   │   │   └── gpatch
    │   │   ├── unzip
    │   │   │   ├── zip
    │   │   │   │   └── bzip2
    │   │   │   └── bzip2
    │   │   └── zlib
    │   ├── [email protected]
    │   │   ├── pkg-config
    │   │   ├── gdbm
    │   │   ├── mpdecimal
    │   │   ├── [email protected]
    │   │   │   └── ca-certificates
    │   │   ├── readline
    │   │   │   └── ncurses
    │   │   │       ├── pkg-config
    │   │   │       └── gpatch
    │   │   ├── sqlite
    │   │   │   ├── readline
    │   │   │   │   └── ncurses
    │   │   │   │       ├── pkg-config
    │   │   │   │       └── gpatch
    │   │   │   └── zlib
    │   │   ├── xz
    │   │   ├── bzip2
    │   │   ├── expat
    │   │   ├── libffi
    │   │   ├── libxcrypt
    │   │   ├── ncurses
    │   │   │   ├── pkg-config
    │   │   │   └── gpatch
    │   │   ├── unzip
    │   │   │   ├── zip
    │   │   │   │   └── bzip2
    │   │   │   └── bzip2
    │   │   ├── zlib
    │   │   └── libnsl
    │   │       ├── pkg-config
    │   │       └── libtirpc
    │   │           └── krb5
    │   │               ├── [email protected]
    │   │               │   └── ca-certificates
    │   │               └── bison
    │   │                   └── m4
    │   ├── pkg-config
    │   ├── icu4c
    │   ├── readline
    │   │   └── ncurses
    │   │       ├── pkg-config
    │   │       └── gpatch
    │   └── zlib
    └── ncurses
        ├── pkg-config
        └── gpatch

will not typically need to be built outside of CI

One of the reasons build deps always matter (besides bootstrapping from scratch etc.) is because of the non-x86_64 case. Which will get even more relevant if we're going to be using a newer GCC than what most people have.

[danielnachun]

Does texinfo actually need gettext? Or is that also a spurious dependency?

[Bo98]

Or is that also a spurious dependency?

Could be. Haven't had a proper look at that.