Gpgconf uses the configuration file as advertised by gpg.
For example:

  $ gpg2 --gpgconf-list | grep ^gpgconf-gpg.conf:
  gpgconf-gpg.conf:16:"/home/wk/.gnupg/gpg.conf
  $ gpg --gpgconf-list | grep ^gpgconf-gpg.conf:
  gpgconf-gpg.conf:16:"/home/wk/.gnupg/gpg.conf

  $ touch ~/.gnupg/gpg.conf-1

  $ gpg2 --gpgconf-list | grep ^gpgconf-gpg.conf:
  gpgconf-gpg.conf:16:"/home/wk/.gnupg/gpg.conf
  $ gpg --gpgconf-list | grep ^gpgconf-gpg.conf:
  gpgconf-gpg.conf:16:"/home/wk/.gnupg/gpg.conf-1

Thus you only need to create a gpg.conf-1 (or conf-2) and you are
done. This is an installation problem.

Of course it can be fixed by changing the config files. However, the default
behaviour (if I start gpgconf as a new user) is to use the shared config file
for both versions. As I see it, programs are responsible to set up the
configuration in the user's home directory if they need one - at least, that's
common practice in my experience.
If this is not a bug in GnuPG, then whose installation problem is this?

The one who decided to install both versions while at the same time using an
option not available for gpg1. It might be caused by a package manager.

So you are saying, every distribution supporting a co-installation should patch
GPG to fix this?
The user might not even know what gpg is, that several major versions exist, or
which options are available where. He just sees email encryption not working any
longer. In most cases, he won't have decided to install both versions - he just
has software installed which, indirectly, depends on both.

Actually we have a solution here since 1.4.13: For example if the conflicting
option is "foo-me", you would put this line into gpg.conf:

ignore-invalid-option foo-me

and gpg will silently skip that option. Of course you need to put the above
line before the line with foo-me.

This has not yet been announced to avoid abuse but if at anytime in the future a
real problems pops up, we will have a workaround already deployed.

Real problems have already popped up years ago:

https://bugs.kde.org/show_bug.cgi?id=226630
https://bugs.kde.org/show_bug.cgi?id=246808

So gpgconf could add, for example, "ignore-invalid-option log-file", to the
configuration file if a log-file option is emitted, and then GnuPG2 would still
honour this option, but GnuPG1 would silently ignore it?

Well my suggestion would be that gnupg reads configuration values from
gpg.conf-version AND gpg.conf so that one could keep common options in gpg.conf
and write version specific ones to gpg.conf-version.

But with the ignore-invalid-option option we can at last fix this from the KDE
side. Werner do you have any idea how one can get the list of supported options
from gpg 1 in a reliable way? So that one could check which options are
supported by gpg1 or will there be no options added to gpg1 in the future?

No, that is way too complex and will easily lead to a combinatorial explosion.
Both versions should not be installed on a standard system. For migration
purposes this is possible but it should always be viewed as an exception.
gpgconf shall never do that. If there is a problem, the user/admin needs to fix
it. I wish we never had introduced those version specific conf files.

Andre: "gpg --dump-options" is supported for 15 years or so and thus an easy way
to figure out which options are available.

I strongly suggest to have an official recommendation how to solve this issue.
The currently available information does not help packagers and application
developers enought to get it right. Probable most distributions should prevent
gpg1 and gpg2 to be installed with their dependency handling.

Werner, you closed this issue with (the now removed) T1448 (wk on Jun 24 2014, 01:42 PM / Roundup) stating:
"You may use --ignore-invalid-option to list options which are only implemented
by gpg2."

This option seems only to be supported in gpg.conf, not on the command line.
(but this is no problem for me)

And it generally works fine (thank you!), just not in this special case here,
becaue gpg1 accepts the option "--debug-level" as valid, but does not allow
any arguments (neither numbers nor e.g. "basic").

The result (with "debug-level basic" in line 42) is:

$ gpg
gpg: /home/thomas/.gnupg/gpg.conf:42: argument not expected

I'm currently using gpg (GnuPG) 1.4.18 from Debian jessie.

As I understand it, "debug-level" is intended to just be a dummy option in
gpg1 to avoid problems with this option appearing in gpg.conf, correct?
So we have two possible solutions:

• either remove option "debug-level" (and rely on "ignore-invalid-option debug-level")
• or accept an argument for "debug-level"

gpgconf, which is a gnupg 2 tool, can't work with gpg version 1. As soon as you
use options not available in gpg 1 you will run into problems for which there
may or may not be a workaround.

The easy workaround is to use gpg.conf.1 which will be used by gpg 1 instead of
gpg.conf.

Just for the record:
It's gpg.conf-1 or gpg.conf-2 and not gpg.conf.1

My workaround for this problem also was to have a gpg.conf-2 which is then used
by gpgconf and a gpg.conf that is used by gpg 1.

Sorry, I have not used those conf files suffixed for a long time.