On 2017-09-14 at 09:29:48 +0200, Antonio Ospite wrote: > A workaround is to install the gnupg2 package (if this is your preferred > solution then gajim should depend on the gnupg2 package), but I am not > sure this is the right solution, maybe setting GPG_BINARY = 'gpg' is > better? The original reporter of this bug was suggesting this too. > > IIUC the versioned dependency on python-gnupg (>= 0.4.1) should assure > that the installed gnupg package (as an indirect dependency) is indeed > version 2.x and that the 'gpg' binary is indeed gpg2. > > Ideally python-gnupg could make this clearer adding a versioned > dependency on gnupg (>= 2) but it's not a big deal.
Actually, python-gnupg is (now¹) happy to run with either versions of gnupg, and will try its best to provide the same api no matter what the backend is. Now that I think about it giving it a dependency on 'gnupg|gnupg1' may just be the right thing to do to make this situation explicit. If GPG_BINARY isn't used elsewhere in the gajim code (something that I haven't checked yet) IMHO it can just be dropped, and python_gnupg called without a binary name, so that it will use whatever gpg is the default and (hopefully :) ) work out of the box even if that changes. Otherwise, if gajim is forcing the use of one specific gpg version through GPG_BINARY I believe that the right thing to do would be to add an explicit dependency to the package that provides that version, as puython-gnupg itself can't be trusted to provide it (as it has happened in this case) ¹ the previous version could run with gnupg 2.0, but failed with gnupg 2.1, but that has been fixed upstream. -- Elena ``of Valhalla''
