[Pkg-gnupg-maint] Bug#561540: Bug#561540: Bug#561540: use update-alternatives to provide /usr/bin/gpg

[Sune Vuorela]

(I'm on maillist, no need to explicit CC)

On Tuesday 02 March 2010 22:13:10 Daniel Leidert wrote:
> > The other option could be to drop gnupg and just use gnupg2.
> 
> Hm: popcon report for users of gnupg vs. gnupg2: 7:1. I don't consider
> this an option.
> 
> gnupg is further of priority:standard. gnupg2 depends on libcurl, which
> is of priority:optional (see our solution with gnupg). Ditto for several
> other dependencies: libpth20, libksba8 and also Gtk+ and its
> dependencies if you consider to leave the dependency on pinentry-gtk.
> How are your plans here? Further: What about gpgv? Is it shipped with
> gnupg2?
> 
> gnupg2 is IMO not a replacement option for gnupg in Debian atm.

I think that all people-users (as opposed to scripts and such) of gnupg should 
be switched to gnupg2. It is more featureful, interacts better with the agent 
and is what upstream (hi Werner) has said to me in the past was the future.

I also don't think that gnupg1 should be killed, as it is still very good for 
small environments, like the installer and various scripts.

Most of the 'added value' dependencies in gnupg2 is already installed on 
systems for example running X.

And gnupg2 should of course prefer pinentry-qt4 for entering passphrases (yes, 
I am a bit biased here <silly emoticon>)

> > But I think making it an alternative is a better, more incremental
> > step.
> 
> I would like to see this tested, because I have doubts, that one can
> easily switch between them (especially because of a few user reports I
> got - but to be honest: I don't know for sure, that the problems were
> caused by gnupg vs gnupg2).

I have at least recently read parts of gnupg2 sourcecode (to figure out how it 
handled use-agent) and it seems that there is quite a few command line options 
that is 'do nothing' in gnupg2, but is there to help being a non-breaking 
dropin replacement.

I had a long talk with Werner Koch several months ago (summer), which I 
planned to write up and send to this maillist, but for various reasons I never 
got around doing it. My own conclusions after that hour-lang talk was that we 
should ditch gnupg1 for most people-users and go for gnupg2 for those.

There is basically two (or maybe three) ways of getting to the situation where 
people-users use gnupg2 when they install it.
(none of these involves touching the gnupg udebs)

1) Alternatives with gnupg2 having a higher priority
2) Have gnupg2 divert the gnupg1 file
3) Patch every single user oriented software using gnupg (most of it probably 
thru gpgme) to use gpg2 for gpg.


I think 3) is out of the question. basically too hard work and too hard to 
keep up with.


2) doesn't really give the power users the opportunity to say 'no' while still 
having gnupg2 installed. Option 2 is slightly more stable than option 1.


Option 1, which is what mentioned in the subject of these mails, is what I 
consider the most sane option. Basically install gnupg-classic with priority 
1, gnupg-curl with priority 2 and gnupg2 with priority 3 (or multiply 
priorities with 25 to get some sort of buffer space)

Alternatives is slightly more fragile than using dpkg-divert, but it is still 
a much more userfriendly option. (I haven't actually seen alternatives break. 
Only heard rumors that it has happened for some people in the far past)

And I do see it possible to handle before squeeze. I would at least appreciate 
it with my kdepim maintainer hat on.

I guess a very important point, that maybe Werner can answer, if he has gotten 
this far, is:
Is gnupg2 command line compatible with gnupg1 ?  And if not, is it documented 
somewhere where it isn't?

Regards,
/Sune
-- 
Genius, I cannot open the mousepad from Windows 98, how does it work?

You can't uninstall the ethernet hardware on a mouse for getting access over a 
2D front-end over a folder.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20100302/b03ea908/attachment.pgp>