By explicitly supporting this model. Recognize that in the modern usage model you often need to find a trust path to some completely random person you've never met, such as the maintainer of some random software program.
And that you need to support a "good enough" trust model for those cases. What do I mean by that? GPG has two separate things: signatures, and trust levels. When you sign somebody's key, GPG wants to know how confident you are that this person will only sign the keys of people who deserve it. Eg, you can trust that Philip Zimmermann will check fingerprints, but your grandma maybe won't, so her signature isn't worth much if anything.
For the first part, GPG needs a path finding service. That is, when dealing with a "You -> Alice -> Bob -> Carol" path, you can give this service your key ID, Carol's key id, and the service tells you whether any path at all exists between those keys. This should be an automatic API that GPG itself can use, like it uses a keyserver. This used to exist, in the form of some random website run by an university professor that now seems gone. It needs to exist as a proper, official webservice.
For the second, in GPG's normal security model, GPG is going to ask you how confident you are in Bob's cryptographic knowledge and signing discipline. And how the heck could you know? You don't know him, he's a friend of Alice's. She should know that. Some way needs to be invented to deal with this, either by having Alice's signature on Bob's key contain a trust level, or by having a mode in which a signature is at least better than nothing, and you can get some confidence rating based on how many paths you can take to reach the destination.
One thing I've noticed is that package signing has a bit of an issue. It lacks metadata about the package.
I'll use archlinux as an example but the same applies to PPA's in Ubuntu:
Say you add a public key of a third party because you want to install a certain package or add a certain repo. The keyring then trusts that key. But it doesn't trust the key for a specific package. It just generally trusts the key.
From a security aspect your system is not compromised, because the security of your base packages now depends on whether random key for third party is compromised. I.e. you can now install backdoored software because that package you wanted to add is compromised.
It's not really limited to linux repos though, imagine you install a driver on windows and it asks you to trust the signing key. That signing key can now be use to put random malicious software on your windows system.
Is there any reason why this metadata couldn't be added to something like pgp other than it requiring a lot of changes in the tooling?
My view is that it's because GPG sucks, and has been used for things it doesn't want to be used for.
GPG's usage model is a commandline tool, used by a person to verify a signature on a file or such. It has a keyring in ~/.gnupg, and importing keys imports them into this keyring. And it really insists on that.
This whole idea of having a key that only applies to a specific package or repository was never intended in its design. When something like a package manager uses GPG it calls the commandline tool and gives it a home directory and keyring somewhere.
What the world really needs is a GPG library. But not GPGme, which just calls the GPG binary and parses the output.
What is needed is one that dispenses with any ideas about how the end-user is supposed to work and just provides primitives to parse keys and messages, verify signatures, etc, and lets the user make decisions about whether to have a global list of keys, or per-repo keys, use a proper database like postgres, or even not store anything at all if all you need is to parse something. But alas, such things are still scarce, and the prevailing model is just hacking GPG into sort of doing a job it doesn't want to do.
There's also some weirdness on the package handling side. Apparently the modern way of doing things in Debian is that you don't sign a package, you sign the repository metadata instead. This may be motivated by the fact that GPG sucks and is slow (because you're calling a binary that loads libraries, parses config file and databases every time, etc), and calling GPG a thousand times during installation would be a significant slowdown.
As anyone who has had to make code interact with GnuPG will attest, I very much agree its interfaces are not ideal to put it mildly. I'm pretty excited, though, about things like Statless OpenPGP CLI (SOP), or Sequoia's CLI f.ex., and several of the other tools referenced up-thread to handle package signatures are also CLI, so I don't think that's an inherent problem.
Regarding packages, apt supports pinning specific keys or keyrings to specific repositories (via the signed-by attribute), as does debsig-verify (which can pin keys or keyrings to specific policies). On Debian, packages get signed by the maintainers (both the source packages, inside the .dsc file, and for the entire upload, inside the .changes file), which get uploaded and then the repository software takes over and signs both source and binary packages in the metaindices. This was made pretty much designed on purpose, and independently of GnuPG CLI's speed or design shortcomings. The repository needs to handle key rotation, due to expiration, algo renewal, security compromises, maintainers leaving the project (and as such their keys not being trusted anymore), etc. Embedding the signatures into the source or binary packages would mean that they would change content, which implies massive mirroring costs, simple digest verification oddities, and similar. Adding detached signatures for each individual source and binary package would make the inode count explode. The metadata still would need to be signed no matter what, and doing either of those per package signing would also make signature update and repository metadata generation and mirroring extremely painful, as you need to be able to do that atomically. In addition the repository needs to be signed as a whole, because it's really a snapshot of a known state, and while it should be fine to mix and match various repositories (at the user request), that should not be the default (at least within a specific repository state).
And that you need to support a "good enough" trust model for those cases. What do I mean by that? GPG has two separate things: signatures, and trust levels. When you sign somebody's key, GPG wants to know how confident you are that this person will only sign the keys of people who deserve it. Eg, you can trust that Philip Zimmermann will check fingerprints, but your grandma maybe won't, so her signature isn't worth much if anything.
For the first part, GPG needs a path finding service. That is, when dealing with a "You -> Alice -> Bob -> Carol" path, you can give this service your key ID, Carol's key id, and the service tells you whether any path at all exists between those keys. This should be an automatic API that GPG itself can use, like it uses a keyserver. This used to exist, in the form of some random website run by an university professor that now seems gone. It needs to exist as a proper, official webservice.
For the second, in GPG's normal security model, GPG is going to ask you how confident you are in Bob's cryptographic knowledge and signing discipline. And how the heck could you know? You don't know him, he's a friend of Alice's. She should know that. Some way needs to be invented to deal with this, either by having Alice's signature on Bob's key contain a trust level, or by having a mode in which a signature is at least better than nothing, and you can get some confidence rating based on how many paths you can take to reach the destination.