[gentoo-dev] [RFC] gnupg-2 stable plans

[gentoo-dev] [RFC] gnupg-2 stable plans

[Alon Bar-Lev]

Hello,

I want to make gnupg-2 stable.

The problem is that gnupg-1.9 was slotted as slot "1.9" and made stable.

So now we have two slots, slot "0" and slot "1.9".

gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting
should be used.

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

1. Mark gnupg-2 stable, as it blocks older versions, this results in
forcing users to manually unmerge the gnugp-1.9 series, this is the
quickest and simplest migration path.

2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so
migration will be smooth. The problem is that I need all archs to work
with me in timely manner so that this will be possible. I have
bug#194113 waiting for arm, mips, s390, sh, and this only for the
dependencies.

Any thoughts?

Best Regards,
Alon Bar-Lev.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Donnie Berkholz]

On 15:49 Sat 08 Dec     , Alon Bar-Lev wrote:
> Hello,
> 
> I want to make gnupg-2 stable.
> 
> The problem is that gnupg-1.9 was slotted as slot "1.9" and made stable.
> 
> So now we have two slots, slot "0" and slot "1.9".
> 
> gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting
> should be used.
> 
> As far as I see, there are two migration pathes I can use:
> 
> 1. Mark gnupg-2 stable, as it blocks older versions, this results in
> forcing users to manually unmerge the gnugp-1.9 series, this is the
> quickest and simplest migration path.

Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather 
than SLOT 1.9?

> 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so
> migration will be smooth. The problem is that I need all archs to work
> with me in timely manner so that this will be possible. I have
> bug#194113 waiting for arm, mips, s390, sh, and this only for the
> dependencies.

I can imagine this resulting in very weird issues, when you have two of 
the same package installed in the same slot.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Alon Bar-Lev]

On Dec 9, 2007 9:21 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 15:49 Sat 08 Dec     , Alon Bar-Lev wrote:
> > Hello,
> >
> > I want to make gnupg-2 stable.
> >
> > The problem is that gnupg-1.9 was slotted as slot "1.9" and made stable.
> >
> > So now we have two slots, slot "0" and slot "1.9".
> >
> > gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting
> > should be used.
> >
> > As far as I see, there are two migration pathes I can use:
> >
> > 1. Mark gnupg-2 stable, as it blocks older versions, this results in
> > forcing users to manually unmerge the gnugp-1.9 series, this is the
> > quickest and simplest migration path.
>
> Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather
> than SLOT 1.9?

he end result would be one slot... If I need to chose 1.9 or 0, I prefer the
standard is to have slot 0.

> > 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so
> > migration will be smooth. The problem is that I need all archs to work
> > with me in timely manner so that this will be possible. I have
> > bug#194113 waiting for arm, mips, s390, sh, and this only for the
> > dependencies.
>
> I can imagine this resulting in very weird issues, when you have two of
> the same package installed in the same slot.

What?
These are two versions....

If nobody else address this, I will chose the easy way -> option#0.

Best Regards,
Alon Bar-Lev.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Donnie Berkholz]

On 22:49 Tue 11 Dec     , Alon Bar-Lev wrote:
> On Dec 9, 2007 9:21 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > On 15:49 Sat 08 Dec     , Alon Bar-Lev wrote:
> > Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather
> > than SLOT 1.9?
> 
> he end result would be one slot... If I need to chose 1.9 or 0, I prefer the
> standard is to have slot 0.

What happens to people who only have slot 1.9 installed and not slot 0, 
or vice versa? You might want to test a few different upgrade scenarios 
to see what portage does.

> > > 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so
> > > migration will be smooth. The problem is that I need all archs to work
> > > with me in timely manner so that this will be possible. I have
> > > bug#194113 waiting for arm, mips, s390, sh, and this only for the
> > > dependencies.
> >
> > I can imagine this resulting in very weird issues, when you have two of
> > the same package installed in the same slot.
> 
> What?
> These are two versions....

Right, but two versions are never supposed to be installed into the same 
slot. They are during upgrade/downgrade, but that's short-term. Some 
package managers could respond oddly. If you were going to go this 
route, it would again be worth testing in advance.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]


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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Alon Bar-Lev]

On 12/12/07, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
>
> 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 I told you before, I wont slot these two.

Best Regards,
Alon Bar-Lev.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Alon Bar-Lev]

On 12/12/07, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 22:49 Tue 11 Dec     , Alon Bar-Lev wrote:
> > On Dec 9, 2007 9:21 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > > On 15:49 Sat 08 Dec     , Alon Bar-Lev wrote:
> > > Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather
> > > than SLOT 1.9?
> >
> > he end result would be one slot... If I need to chose 1.9 or 0, I prefer the
> > standard is to have slot 0.
>
> What happens to people who only have slot 1.9 installed and not slot 0,
> or vice versa? You might want to test a few different upgrade scenarios
> to see what portage does.

OK, I will try this.

> > > > 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so
> > > > migration will be smooth. The problem is that I need all archs to work
> > > > with me in timely manner so that this will be possible. I have
> > > > bug#194113 waiting for arm, mips, s390, sh, and this only for the
> > > > dependencies.
> > >
> > > I can imagine this resulting in very weird issues, when you have two of
> > > the same package installed in the same slot.
> >
> > What?
> > These are two versions....
>
> Right, but two versions are never supposed to be installed into the same
> slot. They are during upgrade/downgrade, but that's short-term. Some
> package managers could respond oddly. If you were going to go this
> route, it would again be worth testing in advance.

I don't understand... It works quite some time for many people.

Alon.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

Alon Bar-Lev wrote:
> As I told you before, I wont slot these two.

Could you provide a link to reasons that lead you to this decision so
that interested readers can make their own opinion?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Mart Raudsepp]

On K, 2007-12-12 at 07:07 +0200, Alon Bar-Lev wrote:
> On 12/12/07, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> ...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 I told you before, I wont slot these two.

I would like to have the option to have a smaller gnupg version in the
shape of a well maintained upstream GnuPG-1 for any embedded or handheld
devices I might acquire in the future, as I would only need OpenPGP
support on such a limited disk and resource device. Please state a
reason for not providing me, and many other users and developers alike,
from such a choice.
With no slotting I can bet on GnuPG-1 going away shortly after all
architectures have stabled GnuPG-2, or is that not so and such users can
mask >=GnuPG-1.9 and keep using a smaller version that perfectly fits
their needs? If yes, why not slot it as is designed?


Regards,
Mart Raudsepp

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Alon Bar-Lev]

On 12/12/07, Jan Kundrát <jkt@gentoo.org> wrote:
> Alon Bar-Lev wrote:
> > As I told you before, I wont slot these two.
>
> Could you provide a link to reasons that lead you to this decision so
> that interested readers can make their own opinion?

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

Best Regards,
Alon Bar-Lev.

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Alon Bar-Lev]

On 12/12/07, Mart Raudsepp <leio@gentoo.org> wrote:
> With no slotting I can bet on GnuPG-1 going away shortly after all
> architectures have stabled GnuPG-2,

gpg-1.X series will be available as long as upstream maintain it.

> or is that not so and such users can
> mask >=GnuPG-1.9 and keep using a smaller version that perfectly fits
> their needs? If yes, why not slot it as is designed?

Slotting makes logic if there is some advantage of having both slots
installed at the same machine, as gnupg-2 does all gnupg-1 does, there
is no point in slotting, forcing users to mess with eselect in order
to resolve the dependency of other packages with gnupg.

You can always mask >=gnupg-2 if you want the 1.X series on embedded devices.

Best Regards,
Alon Bar-Lev.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]


On Wed, 2007-12-12 at 14:30 +0200, Alon Bar-Lev wrote:
> 
> Slotting makes logic if there is some advantage of having both slots
> installed at the same machine,

Guess it's never been clear to you in upstream announcement that gnupg-1
BENEFITS from gnupg-2 co-existing. Again go back and read the
announcement.

>  as gnupg-2 does all gnupg-1 does,

It does NOT, do a comparison of command line args.

>  there
> is no point in slotting, forcing users to mess with eselect in order
> to resolve the dependency of other packages with gnupg.

You keep bringing up eselect when there is NO need. Apps that are
designed for gnupg2 call gpg2 or link to the -2 version of the .so.
Done, and NO need for eselect. That BS has flown, been sold, or bought
for over a year now :)

Try again with some more BS reasons not to slot :)

> You can always mask >=gnupg-2 if you want the 1.X series on embedded
> devices.

Which I have done for my desktop use for >6 months now. Masking to use a
current version of a package version that will continue to be maintained
in the same slot as a newer version is quite stupid. IMHO.

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]


On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
> On 12/12/07, Jan Kundrát <jkt@gentoo.org> wrote:
> > Alon Bar-Lev wrote:
> > > As I told you before, I wont slot these two.
> >
> > Could you provide a link to reasons that lead you to this decision so
> > that interested readers can make their own opinion?
> 
> http://bugs.gentoo.org/show_bug.cgi?id=159623

Again while there might not be technical issues, what is not covered
there in the bug is why rob users of a choice? Why make users mask a 2.0
version that's in the same slot as a 1.4.x version. Given that both will
be actively maintained.

If they are the same, why maintain 1.4.x at all? Kinda contradicts your
justification and statements that gnupg-2 is a FULL replacement for
gnupg-1. Plus your making Gentoo the ONLY distro where gnupg-1 and
gnupg-2 can't be installed together. Just as upstream DESIGNED them.

Nice one ;) And as I said then and now, good luck on stabilization ;)
That's coming over a year after gnupg-2 was released.

Can someone change the freaking broken record ;)

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

Alon Bar-Lev wrote:
> On 12/12/07, Jan Kundrát <jkt@gentoo.org> wrote:
>> Alon Bar-Lev wrote:
>>> As I told you before, I wont slot these two.
>> Could you provide a link to reasons that lead you to this decision so
>> that interested readers can make their own opinion?
> 
> http://bugs.gentoo.org/show_bug.cgi?id=159623

I've read it, thanks. Are you referring to "There is no point in
installing the TWO (means slot) at the same time.", or do you have
something else?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Santiago M. Mola]

On Dec 12, 2007 4:08 PM, William L. Thomson Jr. <wltjr@gentoo.org> wrote:
> On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
> > On 12/12/07, Jan Kundrát <jkt@gentoo.org> wrote:
> > > Alon Bar-Lev wrote:
> > > > As I told you before, I wont slot these two.
> > >
> > > Could you provide a link to reasons that lead you to this decision so
> > > that interested readers can make their own opinion?
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=159623
>
> Again while there might not be technical issues, what is not covered
> there in the bug is why rob users of a choice? Why make users mask a 2.0
> version that's in the same slot as a 1.4.x version. Given that both will
> be actively maintained.

In short:
* It's upstream's choice.
* <2 is actively maintained and there's no deprectation planned.
* It's not a true drop-in replacement, even if it's fully compatible
with all packages in the tree.
* In some cases, people could get a benefit of using gpg-1, instead of gpg-2.
* There's no need of an eselect module, since gpg2 is supposed to be
called gpg2 and not just gpg.
* Again, it's upstream choice and, after considering the
possibilities, there's no major reason for not following it.

What else is needed for using SLOTs?

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Doug Klima]

William L. Thomson Jr. wrote:
> On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote:
>   
>> On 12/12/07, Jan Kundrát <jkt@gentoo.org> wrote:
>>     
>>> Alon Bar-Lev wrote:
>>>       
>>>> As I told you before, I wont slot these two.
>>>>         
>>> Could you provide a link to reasons that lead you to this decision so
>>> that interested readers can make their own opinion?
>>>       
>> http://bugs.gentoo.org/show_bug.cgi?id=159623
>>     
>
> Again while there might not be technical issues, what is not covered
> there in the bug is why rob users of a choice? Why make users mask a 2.0
> version that's in the same slot as a 1.4.x version. Given that both will
> be actively maintained.
>
> If they are the same, why maintain 1.4.x at all? Kinda contradicts your
> justification and statements that gnupg-2 is a FULL replacement for
> gnupg-1. Plus your making Gentoo the ONLY distro where gnupg-1 and
> gnupg-2 can't be installed together. Just as upstream DESIGNED them.
>
> Nice one ;) And as I said then and now, good luck on stabilization ;)
> That's coming over a year after gnupg-2 was released.
>
> Can someone change the freaking broken record ;)
>
>   
Why don't you step up and offer to help maintain this? If I was Alon, I
wouldn't want to do maintain both just cause you wanted me to. It
increases maintenance load and work he has to do and since he's a
volunteer it's all about scratching his personal itch, since this
doesn't for him.. why should he do it. Clearly it gives you an itch, so
setup up and offer to help maintain.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]


On Wed, 2007-12-12 at 11:11 -0500, Doug Klima wrote:
> William L. Thomson Jr. wrote:
>   
> Why don't you step up and offer to help maintain this?

If your asking me, because I am already over committed. I can't be in
all places doing all things. Plus in this regard I am just a user, and
we should not require devs to step up and maintain every package they
use. Usually it's polite for other devs to look out there if they are
maintaining a package that regular users much less other devs use.

Specific to Doug, like in the case of Firebird if you made a good case
for needing 1.5.x back in tree. I would likely oblige, despite my own
opinion and removing it. To try to be cooperative with other devs and
not force them to maintain a version of a package that I am maintaining
other versions of.

>  If I was Alon, I
> wouldn't want to do maintain both just cause you wanted me to.

Well if you have read his past posts. He already stated he plans to
leave that version in tree, and will maintain it.

http://marc.info/?l=gentoo-dev&m=119746280128793&w=2

"gpg-1.X series will be available as long as upstream maintain it."

It's just a matter of the two being able to co-exist. Not maintained.
Nothing I have seen so far says anything about 1.x versions being
removed and not maintained. We are just talking slots.

>  It
> increases maintenance load and work he has to do and since he's a
> volunteer it's all about scratching his personal itch, since this
> doesn't for him.. why should he do it. Clearly it gives you an itch, so
> setup up and offer to help maintain.

This is not a maintenance issue. Just a slotting issue. I would slot,
but he would likely reverse my changes. I have no interest in a tug and
war co-maintenance of a package.

Plus Alon does seem to be doing good work. It's just the stubbornness
over slots I don't understand at all. So there is little for me to
contribute or do.

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[Robin H. Johnson]

[-- Attachment #1.1: Type: text/plain, Size: 3823 bytes --]

On Wed, Dec 12, 2007 at 10:03:56AM -0500, William L. Thomson Jr. wrote:
> On Wed, 2007-12-12 at 14:30 +0200, Alon Bar-Lev wrote:
> > Slotting makes logic if there is some advantage of having both slots
> > installed at the same machine,
> Guess it's never been clear to you in upstream announcement that gnupg-1
> BENEFITS from gnupg-2 co-existing. Again go back and read the
> announcement.
> >  as gnupg-2 does all gnupg-1 does,
> It does NOT, do a comparison of command line args.
See the attached diff between the argument parsing.
I warned you last time, that it wasn't commandline argumnents, but
configure file arguments. Per bug
http://bugs.gentoo.org/show_bug.cgi?id=159505, upstream has decreed that
nobody should use 'gpg-agent-info' in the configuration file, and
instead, should use either the --gpg-agent-info argument to gpg, or set
the GPG_AGENT_INFO environment variable.

Upstream Seahorse did get this resolved, per bug
http://bugs.gentoo.org/show_bug.cgi?id=164523, which is why GPG2 can go
stable now. Evolution and Thunderbird resolved their issues as well,
which were much less of a problem, as they only used GPG - not tried to
be a gpg-agent replacement like Seahorse.

> > there
> > is no point in slotting, forcing users to mess with eselect in order
> > to resolve the dependency of other packages with gnupg.
> You keep bringing up eselect when there is NO need. Apps that are
> designed for gnupg2 call gpg2 or link to the -2 version of the .so.
> Done, and NO need for eselect. That BS has flown, been sold, or bought
> for over a year now :)
That is bull, and as the crypto herd, we raised it before.

> Try again with some more BS reasons not to slot :)
The most common way for applications to use GPG is via libgpgme
http://tinderbox.dev.gentoo.org/misc/rindex/app-crypt/gpgme for the
large list, KDE is there, so is GNOME [via seahorse]). It's a sucky
library IMO, but it's widely used. The core problem with it, is that it
execs the GPG binary, and that the location binary chosen for execution
is compiled into the library at build-time.

That is, if you have /usr/bin/gpg and /usr/bin/gpg2, you can compile it
against exactly one of them. If you have it built against GPG1, and
happen to need some functionality that is only present in GPG2 (eg
SHA-224 message hashes), you need to recompile gpgme to use gpg2, but
then you run into trouble with your complaint.

Or you could have an eselect module for each non-root user to choose
which GPG they wanted, or you could just avoid the entire issue and
recommend that everybody upgrades to GPG2.

> > You can always mask >=gnupg-2 if you want the 1.X series on embedded
> > devices.
> Which I have done for my desktop use for >6 months now. Masking to use a
> current version of a package version that will continue to be maintained
> in the same slot as a newer version is quite stupid. IMHO.
I think that GnuPG is going to end up with the following case:
- Pick ANY _one_ supported major version of GnuPG, and stick with it.
We used to support 1.2 and 1.4 (not slotted, just one-of). Upstream
GnuPG stopped 1.2 support, and now we support 1.4 and 2.0.

The attached diff shows the difference in the command-line options
supported by GPG-1.4.x vs. GPG-2.0.x.
- The smartcard reader stuff CCID/CT/*SC has moved to be external.
- The list-ownertrust, pipemode, shm-coproc were 1.2 features, marked as
  deprecated in 1.4, and removed in 2.0.

You'll be fine until some GPG-using package wants a feature specific to
GPG2, and then you can either complain at the authors of that app, or
suck it up and upgrade.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #1.2: gnupg-1.4.7-2.0.7-commandline-arguments.patch --]
[-- Type: text/plain, Size: 5283 bytes --]

This is a comparision between the commandline arguments supported by GnuPG
v1.4.7 and v2.0.7. It was produced by grabbing the 'ARGPARSE_OPTS opts' block
from the g10/gpg.c file in each tarball, joining lines where a single option
spanned multiple lines, then sorting and diffing.

Created-by: Robin H. Johnson <robbat2@gentoo.org>

--- gpg1-opts	2007-12-12 18:38:40.000000000 -0800
+++ gpg2-opts	2007-12-12 18:38:44.000000000 -0800
@@ -50,7 +50,6 @@
     { aListKeys, "list-key", 0, "@" }, /* alias */
     { aListKeys, "list-keys", 256, N_("list keys")},
     { aListKeys, "list-public-keys", 256, "@" },
-    { aListOwnerTrust, "list-ownertrust", 256, "@"}, /* deprecated */
     { aListPackets, "list-packets",256, "@"},
     { aListSecretKeys, "list-secret-keys", 256, N_("list secret keys")},
     { aListSigs, "list-sig", 0, "@" }, /* alias */
@@ -58,7 +57,6 @@
     { aListTrustDB, "list-trustdb",0 , "@"},
     /* { aListTrustPath, "list-trust-path",0, "@"}, */
     { aLSignKey, "lsign-key"  ,256, N_("sign a key locally")},
-    { aPipeMode,  "pipemode", 0, "@" },
     { aPrimegen, "gen-prime" , 256, "@" },
     { aPrintMD,  "print-md" , 256, N_("|algo [files]|print message digests")},
     { aPrintMDs, "print-mds" , 256, "@"}, /* old */
@@ -67,6 +65,7 @@
     { aRefreshKeys, "refresh-keys", 256, N_("update all keys from a keyserver")},
     { aSearchKeys, "search-keys" , 256, N_("search for keys on a key server") },
     { aSendKeys, "send-keys"     , 256, N_("export keys to a key server") },
+    { aServer,   "server",      256, N_("run in server mode")},
     { aSignKey,  "sign-key"   ,256, N_("sign a key")},
     { aSign, "sign",      256, N_("|[file]|make a signature")},
     { aStore, "store",     256, "@"},
@@ -74,6 +73,7 @@
     { aUpdateTrustDB, "update-trustdb",0 , N_("update the trust database")},
     { aVerifyFiles, "verify-files" , 256, "@" },
     { aVerify, "verify"   , 256, N_("verify a signature")},
+    { oAgentProgram, "agent-program", 2 , "@" },
     { oAllowFreeformUID, "allow-freeform-uid", 0, "@" },
     { oAllowMultipleMessages, "allow-multiple-messages", 0, "@"},
     { oAllowMultisigVerification, "allow-multisig-verification", 0, "@"},
@@ -109,10 +109,9 @@
     { oCompressLevel, "compress-level", 1, "@" },
     { oCompress, NULL, 1, N_("|N|set compress level N (0 disables)") },
     { oCompressSigs, "compress-sigs",0, "@"},
-    { octapiDriver, "ctapi-driver",  2, "@"},
     { oDebugAll, "debug-all" ,0, "@"},
-    { oDebugCCIDDriver, "debug-ccid-driver", 0, "@"},
     { oDebug, "debug"     ,4|16, "@"},
+    { oDebugLevel, "debug-level" ,2, "@"},
     { oDefaultComment, "default-comment", 0, "@" },
     { oDefaultKey, "default-key", 2, "@"},
     { oDefaultKeyserverURL,  "default-keyserver-url", 2, "@"},
@@ -124,7 +123,6 @@
     { oDefRecipientSelf, "default-recipient-self", 0, "@"},
     { oDefSigExpire, "default-sig-expire", 2, "@"},
     { oDigestAlgo, "digest-algo", 2, "@"},
-    { oDisableCCID, "disable-ccid", 0, "@"},
     { oDisableCipherAlgo,  "disable-cipher-algo", 2, "@" },
     { oDisableDSA2, "disable-dsa2", 0, "@"},
     { oDisableMDC, "disable-mdc", 0, "@"},
@@ -172,7 +170,6 @@
     { oKeyring, "keyring", 2, "@"},
     { oKeyServer, "keyserver", 2, "@"},
     { oKeyServerOptions, "keyserver-options",2,"@"},
-    { oKOption, NULL,	 0, "@"},
     { oLCctype,    "lc-ctype",    2, "@" },
     { oLCmessages, "lc-messages", 2, "@" },
     { oLimitCardInsertTries, "limit-card-insert-tries", 1, "@"},
@@ -185,7 +182,7 @@
     { oLockNever, "lock-never", 0, "@" },
     { oLockOnce, "lock-once", 0, "@" },
     { oLoggerFD, "logger-fd",1, "@" },
-    { oLoggerFile, "logger-file",2, "@" },
+    { oLoggerFile, "log-file",2, "@" },
     { oMangleDosFilenames, "mangle-dos-filenames", 0, "@" },
     { oMarginalsNeeded, "marginals-needed", 1, "@"},
     { oMaxCertDepth,	"max-cert-depth", 1, "@" },
@@ -257,7 +254,6 @@
     { oPasswdFile, "passphrase-file",2, "@" },
     { oPasswd, "passphrase",2, "@" },
     { oPasswdRepeat, "passphrase-repeat", 1, "@"},
-    { opcscDriver, "pcsc-driver",    2, "@"},
     { oPersonalCipherPreferences,  "personal-cipher-preferences", 2, "@"},
     { oPersonalCipherPreferences, "personal-cipher-prefs", 2, "@"},
     { oPersonalCompressPreferences,  "personal-compress-preferences", 2, "@"},
@@ -271,9 +267,8 @@
     { oPhotoViewer,  "photo-viewer", 2, "@" },
     { oPreservePermissions, "preserve-permissions", 0, "@"},
     { oPrimaryKeyring, "primary-keyring",2, "@" },
-    { oQuickRandom, "quick-random", 0, "@"},
+    { oQuickRandom, "debug-quick-random", 0, "@"},
     { oQuiet,	"quiet",   0, "@"},
-    { oReaderPort, "reader-port",    2, "@"},
     { oRecipient, "recipient", 2, N_("|NAME|encrypt for NAME")},
     { oRecipient, "remote-user", 2, "@"},  /* old option name */
     { oRecipient, "user", 2, "@" },
@@ -283,7 +278,6 @@
     { oRFC1991, "rfc1991",   0, "@"},
     { oRFC2440, "rfc2440", 0, "@" },
     { oRFC2440Text, "rfc2440-text", 0, "@"},
-    { oRunAsShmCP, "run-as-shm-coprocess", 4, "@" },
     { oS2KCipher, "s2k-cipher-algo", 2, "@"},
     { oS2KCount, "s2k-count", 1, "@"},
     { oS2KDigest, "s2k-digest-algo", 2, "@"},

[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]

Re: [gentoo-dev] [RFC] gnupg-2 stable plans

[William L. Thomson Jr.]

[-- Attachment #1: Type: text/plain, Size: 6808 bytes --]


On Wed, 2007-12-12 at 20:46 -0800, Robin H. Johnson wrote:
>
> See the attached diff between the argument parsing.

Ok, thank you

> I warned you last time, that it wasn't commandline argumnents, but
> configure file arguments.

Part of that was going from the wrapper to replicate missing commands or
functionality attached to one of the bugs that you had contributed to
creating. Granted it as a band aid at the time, and has expired for the
most part.
http://bugs.gentoo.org/attachment.cgi?id=113289

>  Per bug
> http://bugs.gentoo.org/show_bug.cgi?id=159505, upstream has decreed that
> nobody should use 'gpg-agent-info' in the configuration file, and
> instead, should use either the --gpg-agent-info argument to gpg, or set
> the GPG_AGENT_INFO environment variable.
> 
> Upstream Seahorse did get this resolved,

I tested out working solutions before upstream acted on this. I did give
up on it long ago though.

>  per bug
> http://bugs.gentoo.org/show_bug.cgi?id=164523

Which is a dup of the one you posted above. Both with a TON of comments
from me :) In my suffering days.

> , which is why GPG2 can go
> stable now.

Well I still need to do my own testing. Given that I have used seahorse
daily for > 1.5 years now. I will give it a go, but I am not expecting
to do anything crazy like before to get it working.

Mostly gave up on trying and thus allowed bugs to be closed out of
ignoring the matter till stabilization time :)

>  Evolution and Thunderbird resolved their issues as well,
> which were much less of a problem, as they only used GPG - not tried to
> be a gpg-agent replacement like Seahorse.

Notice how I am not bring up Seahorse at all. The relation there has
kinda convoluted the entire situation wrt to gnupg-2. That being said I
do still have gnupg-2 masked on my system. I had seahorse working at
times in the past with gnupg-2. Per both bugs you posted :) It likely
works now, but not as easily or flawlessly as it does with gnupg-1. Thus
it's been masked for months now. As I got sick of all the HOURS/days
wasted on trial and error there.

Why do I use Seahorse or gnupg/gpg at all? Well it's a Gentoo
requirement :) I have to sign my emails, so wasn't really my choice to
start using. Granted could have use Tbird with Enigmail, but been using
Evo for years. But all the Seahorse stuff is moot now, and I was hoping
to be kept out of this conversation. Because it's pretty irrelevant.

> The most common way for applications to use GPG is via libgpgme
> http://tinderbox.dev.gentoo.org/misc/rindex/app-crypt/gpgme for the
> large list, KDE is there, so is GNOME [via seahorse]). It's a sucky
> library IMO, but it's widely used. The core problem with it, is that it
> execs the GPG binary, and that the location binary chosen for execution
> is compiled into the library at build-time.

And what upstream maintains gpgme, and what is their relation to gnupg?
Even seahorse tracked it's problems down to that or at least blamed it
on that. Seems like more work should be done with gnupg and gpgme, since
they are both gnupg.org projects. Verses other things using gpgme or
etc. Which are external projects.

> That is, if you have /usr/bin/gpg and /usr/bin/gpg2, you can compile it
> against exactly one of them. If you have it built against GPG1, and
> happen to need some functionality that is only present in GPG2 (eg
> SHA-224 message hashes), you need to recompile gpgme to use gpg2, but
> then you run into trouble with your complaint.

Um well from what I have seen on other distros is exactly that. Apps
will link against one or the other. Based on how gnupg compiles things
normally, and which version a package deps on. Gnupg-2 build system
spits out gpg2, not gpg. We are making gpg there via a symlink. So any
other project using gnupg, would likely expect to see gpg2 and -2.so if
it were to use 2.x. Per upstream no?

> Or you could have an eselect module for each non-root user to choose
> which GPG they wanted, or you could just avoid the entire issue and
> recommend that everybody upgrades to GPG2.

Seem like the choice on which gpg to use is a upstream choice per
project. I guess you could take it one step further with eselect and
giving users a choice there. But that's not 100% necessary. Again if
they have a problem with a package deping on a gnupg 1.x verses gnupg
2.x. They can take the matter up with upstream or etc.

Obviously less of an issue now, as it was a year ago. But this type of
thought process is what held gnupg-2 from going stable on Gentoo for
over a year after first release.

> I think that GnuPG is going to end up with the following case:
> - Pick ANY _one_ supported major version of GnuPG, and stick with it.
> We used to support 1.2 and 1.4 (not slotted, just one-of). Upstream
> GnuPG stopped 1.2 support, and now we support 1.4 and 2.0.

Yes, but unlike 1.2, and 1.4. Upstream has designed 1.x and 2.0.x to be
able to co-exist. I fail to see why that doesn't work for us on Gentoo.
When it works on all others. I get your points mentioned above. But have
always had counters to them.

> The attached diff shows the difference in the command-line options
> supported by GPG-1.4.x vs. GPG-2.0.x.
> - The smartcard reader stuff CCID/CT/*SC has moved to be external.
> - The list-ownertrust, pipemode, shm-coproc were 1.2 features, marked as
>   deprecated in 1.4, and removed in 2.0.

Looked like there were one or two others, not sure if they are part of
the above or not? Or what they do either way :)

> You'll be fine until some GPG-using package wants a feature specific to
> GPG2,

Then the package deps should be updated to reflect the version of gpg it needs.

>  and then you can either complain at the authors of that app

Sure like I/we had to do for seahorse. Which didn't happen over night,
and depgraph problems carried on for a bit (few months) in the mean
time.

>  or suck it up and upgrade.

I tried to many times, and so did many others :) Much of that record is
the bugs you posted.

Also how does this address the embedded or server use issue? Not package
deps or technical issues. But uses our users might have or etc. Or how
does it address the issue that gnupg-1 can benefit from using gnupg-2's
gpg-agent for passphrase caching.

I thought I was pretty clear before when I said all technical issues had
been resolved. Short of how stabilization would be handled, and moving
from two slots back to a single.

This is purely about robing users of a choice. Deviating from upstream
design, and all other distros. Not to mention making things harder than
they need to be and slowing things down for year.

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [RFC] gnupg-2 stable plans

[Alon Bar-Lev]

Hello,

I selected the blocker option, forcing users to unmerge gnupg-1.9.
Users that used only 1.9 slot, will be notified later by revbumping this slot.

I am truly sorry for bothering users, but this is the only way to push
this forward.

Thank you for your comments,
Alon Bar-Lev.

BTW:  If someone what to step forward and maintain gnupg, I will be most happy!
But this derives maintaining all g10 Code GmbH software, as they are
closely related.
dev-libs/libgcrypt
dev-libs/libksba
dev-libs/libgpg-error
app-crypt/pinentry
dev-libs/libassuan
app-crypt/dirmngr
app-crypt/gpgme

And probably more.

On 12/8/07, Alon Bar-Lev <alonbl@gentoo.org> wrote:
> Hello,
>
> I want to make gnupg-2 stable.
>
> The problem is that gnupg-1.9 was slotted as slot "1.9" and made stable.
>
> So now we have two slots, slot "0" and slot "1.9".
>
> gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting
> should be used.
>
> As far as I see, there are two migration pathes I can use:
>
> 1. Mark gnupg-2 stable, as it blocks older versions, this results in
> forcing users to manually unmerge the gnugp-1.9 series, this is the
> quickest and simplest migration path.
>
> 2. Perform slot-move of slot "0" and slot "1.9" into slot "2", so
> migration will be smooth. The problem is that I need all archs to work
> with me in timely manner so that this will be possible. I have
> bug#194113 waiting for arm, mips, s390, sh, and this only for the
> dependencies.
>
> Any thoughts?
>
> Best Regards,
> Alon Bar-Lev.
>
-- 
gentoo-dev@gentoo.org mailing list