systems with a modern Linux kernel (> 3.17) really should use the getrandom interface rather than reading from /dev/random or /dev/urandom directly. See [random(7)](http://man7.org/linux/man-pages/man7/random.7.html) for more details about the different options avalable today.
We don't want to generate keys before the kernel's PRNG has been adequately seeded. But once it's seeded, it's not clear that we have any security gain from waiting for more "external entropy", whatever that source is. Indeed, djb has argued that an attacker capable of controlling the inputs to your seeding algorithm might gain an advantage in a continuous-seeding scenario that they wouldn't get in a seed-once-and-done approach.
/dev/urandom is clearly not acceptable because it doesn't block at all when the PRNG hasn't been seeded. But /dev/random is also problematic because of the severe delays it incurs, especially on systems with few sources of external entropy. These delays cause usability problems, and some of those usability problems turn into security problems.
If the kernel says that the PRNG is seeded, then GnuPG should just use it. as random(7) says:
The cryptographic algorithms used for the urandom source are quite conservative, and so should be sufficient for all purposes.
if the kernel is going to lie about seeding, then it could also lie about "available entropy" in /dev/random as well. So it doesn't make sense for GnuPG to treat the kernel as adversarial in making this decision.
Looking at the table in random(7) it seems clear to me that what we want to just invoke getrandom() with no arguments. This blocks until the kernel's PRNG has been adequately seeded, but once seeded it doesn't block, while still pulling from an unbreakably-strong PRNG. this is the best-of-both-worlds situation that we want.
Changing the GnuPG long-term (and short-term) key generation techniques to use this approach might require coordination with gcrypt. gcrypt's gcry_random_level currently has GCRY_WEAK_RANDOM and GCRY_STRONG_RANDOM and GCRY_VERY_STRONG_RANDOM, which doesn't represent the nuance described above.
One approach might be to just have gcrypt on Linux treat all values of gcry_random_level the same, and use getrandom() for all of them.