[Pkg-gajim-maintainers] Bug#874791: gajim: Crash on startup with python-gnupg >= 0.4 without gpg1

Elena ``of Valhalla'' valhalla at trueelena.org
Thu Sep 14 08:27:30 UTC 2017


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''



More information about the Pkg-gajim-maintainers mailing list