@andrewnez Syft also has the problem of trying to figure out what a binary blob of stuff is. This feels like maybe it's time for something bigger

We look for various strings in the binary today (yara would be even better, but there isn't a nice yara go library we could find)

https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/binary/classifiers.go#L18

> Same library, four names, no mapping between them.
Do you know about repology?
https://repology.org/project/openssl/versions
There's also an API/database: https://repology.org/api/v1

@andrewnez I think this touches the core issue:

> None of these mechanisms really declare
> C dependencies in a machine-readable way.

C libraries can't even express their own *API*/*ABI* in a machine-readable way¹, so no surprise that the bigger steps are also missing!

C people have been quite content with the status quo, as it's a crucial part of upholding their ABI monopoly.

¹ Outside of your package manager shipping with its own C compiler that parses C header files.

@andrewnez the title feels weird. If Python packaging Rust dependencies has the same problem, why is it the "C-shaped" hole? Isn't it just a "other ecosystems" hole?

@andrewnez This is good and I'm stoked you're diving into this particular rabbit hole, more awareness will help build bridges and resolve the issues!

@andrewnez Have PEPs 725 and 804 crossed your radar in the past couple of years? (they're currently stalled as far as I know, but they're Python's most recent attempt at closing the external dependency gap without relying solely on bundling)

@andrewnez as a data point, opam does track 'system dependencies' and helps automate their installation as part of the OCaml package installation; e.g. https://github.com/ocaml/opam-repository/blob/master/packages/conf-cairo/conf-cairo.1/opam