On Sat, 2007-12-08 at 15:49 +0200, Alon Bar-Lev wrote:
>
> gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting
> should be used.

Drop in according to YOU, which I have taken issue with since 1/1/07.

Per last upstream release, and every one since 2.x was release, just as
I have quoted and stated many times before.

 http://lists.gnupg.org/pipermail/gnupg-announce/2007q3/000259.html

"GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that
it splits up functionality into several modules.  However, both
versions may be installed alongside without any conflict.  In fact,
the gpg version from GnuPG-1 is able to make use of the gpg-agent as
included in GnuPG-2 and allows for seamless passphrase caching.  The
advantage of GnuPG-1 is its smaller size and the lack of dependency on
other modules at run and build time.  We will keep maintaining GnuPG-1
versions because they are very useful for small systems and for server
based applications requiring only OpenPGP support."

> As far as I see, there are two migration pathes I can use:

There is a third you have refused for almost a year now.

1.x should remain slot 0, 2.x should be slot 2.

http://bugs.gentoo.org/show_bug.cgi?id=159623

I also mentioned that if left unaddressed I would challenge this issue
when it came time for stabilization. Which gnupg2 was release over a
year ago now. Main reason that held it back so long was refusal to slot
2.x versions, in any slot other than 0. Just as 1.9 was slotted.

Even if all technical issues with gnupg 2.x have been worked out. It is
NOT a drop in replacement for 1.x. The two are different and DESIGNED to
work together. We will effectively rob users of the choice of 1.x for
what ever reasons and force 2.x on them. Which deviates from all other
distros.

Not to mention we symlink gpg -> gpg2, and gpg2 does not implement all
features of gpg, command line args. By default upstream spits out the
binaries on build with different names, same thing with .so's and etc.
So there isn't any conflict/collision problems. In fact just the
opposite if one hits gpg expecting a gpg command feature set, and
instead getting a gpg2 one.

I have wasted weeks on this posting on comments on bugs. Brought up the
issue here before. We have lost a year wrt to gnupg 2. I am all for
moving forward and dropping legacy versions of packages from the tree.
But this is not one IMHO.

Last post on this topic, ever for me. It's WAY stupid at this point. The
horse has been beaten to death, exhumed, killed again, re-exhumed,
mummified, put on exhibit, taken down, killed again, and re-buried :)

-- 
William L. Thomson Jr.
Gentoo/Java