These bug reports are sometimes mixing two different issues: The
debian-keyring and r/o keyrings for other purposes.

The debian keyring is afaik used with gpgv and has the special
property that all keys in it are fully trusted. In short: It is a set
of keys only to be used by gpgv. Thus the issue is how to create this
keyring. Currently I suggest to use gpg --export LIST-OF-KEYIDS to
create it. In some distance future a little conversion tool might be
required to convert the OpenPGP transport format for keys into the
database format used by gpgv. The bottom line is that I don't see
that as an issue and the Debian readme seems to support this point of
view.

The other issue is that of multiple keyrings. Over the years we tried
several approaches to get it right but none of them worked reliable.
The problem is the usual one of keeping two databases in sync.
Aggravated by the requirement to keep some of them read-only but still
allowing to update them somehow. Approaches like preferring the
writable one over the read-only one work in theory but will lead to
administrative headaches. We will never be sure which keyblock is
actually used. (I had a similar problem today with VPATH builds where
two different header files, both are created from the same source,
provoked a bug in certain environments - not particular easy to
understand what was going on)

What I plan with GnuPG 2.1 is to rework the keyring situation by
replacing keyrings it with a new format (keybox). This new format
allows to keep meta data and also will boost key access times. This
will make it possible to flag keys as read-only or allow updates only
with a new options set. I am actually working on 2.1. However,
before we implement such extravagant feature it will be wetter to
collect real world use cases. We should do this on gnupg-devel@.

One such use case might be to automatically import certain keys into
the keybox for future use. This is basically the idea of reading the
writable keyring first and only then the read-only ring
(write-on-demand). The solution I have in mind is to import such
read-only keys using the established --auth-key-locate feature.

@werner do you have any updates on this?