Hello, I believe that part of distribution function is to provide a simple and maintainable system to its users.
If upstream is doing something wrong, we don't have to move the problem to our users to handle, but handle/solve the problem on behalf of our user base. The gnupg issue falls in this category. It looks like this upstream (g10) made some incorrect decisions. They wanted to make gnupg modular, this indeed correct approach, as gpg and gpgsm have a lot in common. But as they were doing so they also broke backward compatibility of "gpg" command-line. They had not needed to do so, but they chose to do so anyway. Their solution to the problem was to install gpg utility for version 1.X and gpg2 utility for version 2.X. But now, applications should be aware which version they work with, as the filename was modified. Forcing users to keep both versions around for infinite. For us and our users, maintaining this kind of a solution is much more complex, and will introduce hidden costs, as you don't know which version is used by which component. The correct solution is to keep backward compatibility of the interface, and make the software modular.... If upstream doesn't care, someone should. Backward compatibility is gone... We cannot do much about this. So the only thing we can do is modify application to use the new interface if required. This will enable us to provide much simpler configuration for our users. The funny thing is that even gpgme, a g10 solution, does not work correctly with both gnupg-1.X and gnupg-2.X... Even latest release (1.6 a week ago) did not pass its own internal tests. g10 is one of the worse upstreams I have ever worked with... They keep breaking their software, and uncooperative when it comes to bug reports, look at bug#204662. For example, they notified that soon applications will not be able to pass the passphrase to gpg via command-line or file description. This will surely break almost any batch application. The only regression left is mail-client/squirrelmail gpg plugin. http://bugs.gentoo.org/show_bug.cgi?id=202406 If someone has this installed, know some php and willing to help, it would be great! Its upstream is aware of this issue, and looks like doesn't care. Best Regards, Alon Bar-Lev. On 1/9/08, William L. Thomson Jr. <[EMAIL PROTECTED]> wrote: > First off to get the apology out of the way. Me being a user of both > seahorse and gnupg, I wasn't fully aware of the mess going on in between > the two. So in that regard I do apologize to Alon Bar-Lev ( alonbl ). > Things are not so cut and dry, and I could see where one might have the > need for eselect there. Although there might be other options as well. > > The story as clear and concise as I can make it. Yes upstream created > gnupg-1 and gnupg-2 to co-exist. However upstream did not do anything to > address a VERY popular wrapper to gnugp, gpgme. Presently most apps like > seahorse use gpgme to interface with gnupg. Instead of doing it > directly. At the present time you end up linking gpgme to either gnupg-1 > or gnupg-2. No means to do both, and that's where the eselect part comes > into play. Ideally apps should interface directly, but upstream didn't > really encourage that, and it's why gpgme exists in the first place. > Which might die. > > There are other issues, like gpgme executing gpg on each invocation. So > it's hardly ideal and from what Robin (robbat2) has told me. They might > be getting rid of gpgme and/or introducing a --server flag or something > like that for gnupg. Not 100% clear there and doesn't really matter per > our present problems and situations. But would be a performance benefit > from that change :) > > Despite other distros shipping both gnupg-1 and gnupg-2. They are just > now seeing the problems. Because being binary, I don't believe gpgme was > ever linked against gnupg-2. So it's there for users, but apps really > aren't bound to it. So some like Debian are hitting this now, when we > ran into it a year ago. > > Now that their is full understanding, and some clarity. It still doesn't > present us with a solution at this time. Seems like most all issues with > gnupg-2 have been worked out, but a few remain. Not sure how important > it is to address those. I have no doubt both Alon and Robin are working > on those as time permits. > > Slots and eselect is one way to go. I mentioned to Robin, maybe doing a > USE flag on gpgme, to control what it's bound to, like gpg2 or gpg, > since the later is already a USE flag I believe. Slotting both in the > mean time, till the gpgme mess is cleared up. That way users could chose > what gpgme is linked to, and still use gnupg-2/gnupg-1 or etc. But like > before, totally up to those working on it, Alon and Robin. > > Anyway just wanted to take a moment to apologize a bit. It's quite a > mess, and I do appreciate those in Gentoo undertaking it, and seeing it > through. Very sorry for any flack or abrasiveness. Just got sucked into > all this as just a user of said apps. > > But really most all are problems are gpgme. Upstream is JUST now > starting to acknowledge that problem. When people have been pointing it > out for over a year :) It's a wonderful mess. > > -- > William L. Thomson Jr. > Gentoo/Java > > -- gentoo-dev@lists.gentoo.org mailing list
