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
signature.asc
Description: This is a digitally signed message part
