Werner Koch wrote... > On Sun, 14 Mar 2021 14:32, Christoph Biedl said: > > > Point is, the legacy file ~/.gnupg/options is still being used in > > surprisingly many applications, also in documentation: > > Then please file a bug against such documentation. And maybe even > against any application which read the option filre directly, that is > without using gpgconf.
If Debian were not rather late in the freeze for Bullseye, I would already have started the according procedure (Mass Bug Filing). But given the release progress, this will not succeed in time. For *after* the release, everything will be possible. My intent is to keep impact for the current release low. > > https://codesearch.debian.net/search?q=.gnupg%2Foptions&literal=1 > > Look at the code shown tehre: Almost everywhere it is used as a fallback > from gpg.conf. Still some places do, or point to the wrong location. Also there might be other programs that rely on the legacy location. "Turning things off permanently is surprisingly difficult." > > In Debian, revert that commit, and emit a deprecation warning if the > > legacy file is parsed. > > Sysadmins will kill you if you do that. The global conf file has been a > long standing request from many parties. It comes very hadny for large > installations because it can be used to enforce options on users. That > is why I took the trouble to actually backported this from master. No doubt about the benefits of the new concept. However, sysadmins of Debian systems could not benefit from that (yet), so I feel safe. Still there are a lot of reasons why reverting is a bad idea, I will not follow that approach. > Supporting the legacy option file would be a Bad Idea. In particular > for a new major release it should be not a problem to add release notes > mention that after 18 years the deprecated legacy option file is not > anymore supported. While it was deprecated a long time ago, until very recently users had little chance to know about this, and therefore no reason to adopt. So this comes as a surprise, and as a short-time and massive change, as seen in this bug report. I really want to avoid users' workflows will break galore, possibly without even being really noticed. The best solution would have been to start emitting deprecating warnings at some point in the past. But past cannot be changed. My preferred solution was to restore the old behaviour for a limited time, i.e. parsing the legacy config file, plus emitting that warning. This will give everybody a chance to adjust their configuration. Second in preference was to only emit that warning, without processing the file. Providing a warning in the release notes and other places is very easy to do. But from experience I doubt this reaches the majority of affected users in time. Which is why I except to create havoc if this was the only reaction to this change. Christoph
signature.asc
Description: PGP signature