PackageURLTypeForValues mints the non-spec pkg:homebrew; the specification's type is pkg:brew #75

Split out of #70, which fixed the read direction only.

The gap

The purl specification defines Homebrew packages as pkg:brew (purlkit/testdata/purl-spec/types/brew-definition.json: "Homebrew packages for macOS and Linux"). Bomly's ecosystem token is homebrew, and purlkit.TypeForValues has no explicit case for it, so it falls through to the verbatim fallback and mints pkg:homebrew — a type the specification does not define.

That is the exact failure the TypeForValues doc comment warns about: "without one we emit a type that is not in the purl spec, and consumers keyed on the type (OSV, SBOM ingest) silently fail to match."

The read direction is now fixed — #70 added "brew": "homebrew" to purlTypeEcosystems, so an ingested pkg:brew resolves to EcosystemHomebrew instead of no ecosystem at all. The mint direction was deliberately left alone there, because it is a different kind of change.

Why it was not fixed in that PR

Changing what TypeForValues("homebrew") returns changes minted package URLs, and a DependencyNode's ID is its canonical purl. So every Homebrew node's ID changes, which moves graph identity, merge keys, and anything downstream keyed on them. That needs its own change with its own thinking about what happens to already-emitted documents — not a row added alongside an unrelated export.

Ask

Add an explicit case "homebrew", "brew": return "brew" to purlkit.TypeForValues, and decide what the change means for identities already on the wire:

• whether pkg:homebrew must keep resolving on ingest (it does today, via canonicalEcosystems, and should keep doing so regardless);
• whether anything needs to treat the two spellings as the same node when merging documents produced before and after the change.

TestEcosystemForPURLTypeRoundTripsTheEcosystemVocabulary in purlkit_delegation_test.go covers the round trip and should stay green through it (homebrew → brew → homebrew).

Worth checking at the same time

githubactions is in the same class: Bomly and Syft both key GitHub Actions on pkg:githubactions, which the specification does not define either (it defines pkg:github for repositories, which is a different thing). Unlike brew there is no correct spec type to move to, so it is probably a documented deviation rather than a bug — but it should be written down as one. #70 records the reasoning in specTypesOutsideTheEcosystemVocabulary.