Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup"): > On Wed 2016-10-19 05:47:02 -0400, Ian Jackson wrote: > > If gnupg doesn't guarantee that v1's will work with v2 then you don't > > have an upgrade path for your users. > > We do have an upgrade path currently from v1.4.x to v2.0.x and v2.1.x. > However, i don't know whether GnuPG upstream is willing to guarantee > that v1 will work with v2.4.x. If you want things to be arbitrarily > portable, you should use the portable data formats.
I think this bug #841143 is about a race in this upgrade path. Do you intend to investigate or fix this race ? > > I'll take your answer as a declaration that downgrading is not > > supported. Unfortunately I think this means you have a bug. > > > > For example, consider schroots, which typically contain /home. > > an schroot will also work when upgraded across single debian versions. No, I think you misunderstand. An schroot typically shares its /home with the "outside" system. People often use such chroots for running newer versions of things on an older system, or vice versa, whenever that's needed. If I have a jessie system with a stretch chroot, and I run `gnupg' in the stretch chroot, gnupg's conversion will mess up my ~/.gnupg so that my main system does not work any more. I'm sorry to say that I think this all seems quite ill-advised. > I'm afraid you're simply not going to get the fastest possible > conversion if you do incur an upgrade during your test suite's > migration. sorry! Can you at least make the migration work every time ? > > Also there are institutions where all the home directories are on NFS. > > Obviously one wouldn't recommend putting GNUPGHOME on NFS, but there > > might be reasons why it's OK in context. > > > > In both of these situations the same ~ may be operated on by programs > > from different Debian releases (or non-Debian operating systems) in > > any arbitrary interleaved order. > > I believe upstream is aware of this, which is why they've declared (for > example) that gpg 2.0 and gpg 2.1 are not "co-installable". This is a very broad definition of "co-installable". In practice an admonition not to use gnupg1 and gnupg2 with the same ~ is going to be impractical to comply with. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.