It seems 2.0.1 should be slotted. Apps like seahorse dep on gnupg 1.2.x or 1.4.x. The upgrade of gnupg to 2.0.1 causes breakage, and therefore should be slotted.
GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.5) 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. 2.0.x needs to be in slot1 please thanks
There is no point in keeping both versions installed. gpg-2.X series is a full replacement gpg-1.X series. > The upgrade of gnupg to 2.0.1 causes breakage Which? Can you please explain?
>> Comment #2 In this case, someone needs to fix the app-crypt/seahorse dependency (in offical portage and gentopia overlay please).
The points for keeping both versions were covered in detail in Comment #1. With regard to seahourse it's not a dependency issue. Seahorse requires 1.2.x or 1.4.x per upstream. checking for appropriate GnuPG version... configure: error: Appropriate version of GnuPG not found. Please install version 1.2.x or 1.4.x Introducing 2.0.1 without a slot has caused unacceptable breakage. Which it seems no one looked into, or resolved before 2.0.1 was committed. Not to mention circular deps. Since one would emerge 1.4.x for seahorse, then portage would pull in 2.0.1. Then one has to go emerge 1.4.x again, and so on. So there are multiple reasons to slot, and it needs to be done, not debated. Once packages like seahorse or others are modified upstream to use or work with 2.0.1 then it will be moot. But that time is not now, and you can't go and break packages that used to work and install. Just because your moving forward with a dep. Now again per comment #1 there are reasons to keep the 1.x packages around. So it's not likely they can be removed from tree anytime soon. Please slot this package to fix the resulting breakage that has occurred. Thank you.
(In reply to comment #2) > There is no point in keeping both versions installed. > gpg-2.X series is a full replacement gpg-1.X series. > > > The upgrade of gnupg to 2.0.1 causes breakage > > Which? Can you please explain? > It is not a point of which the slot needs to be fixed. If you do not wish to do I will speak with dragonheart about fixing it. The reason being not all applications want/need version 2 some of us need version one for server stuff while using version 2 for other stuff hense upstream ensured we could install it slotted.
(In reply to comment #5) > It is not a point of which the slot needs to be fixed. If you do not wish to > do I will speak with dragonheart about fixing it. Go ahead... Are you trying to frighten me? > The reason being not all > applications want/need version 2 some of us need version one for server stuff > while using version 2 for other stuff hense upstream ensured we could install > it slotted. Nobody is going to remove 1.X series. If you like to install it you may mask >=app-crypt/gnupg-2.0.0 There is no point in installing the TWO (means slot) at the same time. The above reason is not a good enough reason to slot. Please try to find some other. --- Crypto herd, please comment here... If we want to slot gnupg, we need also: 1. Create virtual/gnupg. 2. Create and maintain eselect-gnupg to allow selecting the right version. 3. Modify gnupg-1.X ebuild so it install gpg1, gpgv1 so that we can link gpg, gpgv to the right product version. 4. Update all ebuilds to depend on virtual/gnupg instead of explicit version. But I really don't see any reason to do so, since there is no point in installing both versions at the same time.
Wasn't so much a scare tactic, as it was there is breakage that needs to be fixed. Please understand upstream has developed GnuPG-2 to be able to co-exist with GnuPG-1. http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000242.html "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. " It seems GnuPG-1 can also use and benefit from GnuPG-2 being present. So there is reason and justification to have both present. Granted I am not aware of an app or situation where both would be required at this time. Other than to support legacy and current apps. As in the current situation to remedy breakage. It's possible seahorse will never use GnuPG-1 as upstream is not deprecating it's use, or phasing it out. It seems there will be further development and releases of GnuPG-1. Bottom line, the package has cause breakage in the tree which must be resolved. However ever you want to resolve it. Previous comments weren't meant for intimidation. They were meant to express the breakage must be fixed, and if you don't want to fix the breakage. Others can and will, because breakage is not acceptable. If virtuals, eselect, and etc are required to properly slot the package in your view. Then the package should have been kept in an overlay or packaged masked and developed further before introducing to the tree or unmasking.
Changing severity to blocker on behalf of Anarchy.
(In reply to comment #6) > (In reply to comment #5) > > It is not a point of which the slot needs to be fixed. If you do not wish to > > do I will speak with dragonheart about fixing it. > > Go ahead... Are you trying to frighten me? > Dude I used to be part of crypto herd ... I know the importants of slotting it. If you do not like the fact that it needs to be slotted then maybe someone else in herd should maintain it. Dragonheart is the lead last I checked for crypto herd so if you have proplems with people speak to the lead of a herd then maybe gentoo is not right for you. Your attitude stinks, a little heads up "I was retired when I thought my shit did not stink" keep pushing on devs and users and your life with gentoo wont be long, make sure you think before you speak.
Alon: Why can't this be simply slotted? Upstream designed it to work side by side. So we should respect that
I go on a short vacation, and all hell breaks lose? Chill out people. Prior to 2.0, 1.9 contained the new development stuff (mainly agent and S/MIME), and was installed in parallel to 1.4, because upstream recommended that people use the 1.4 series for relibable OpenPGP (so they could break S/MIME if they had to). Thus 1.4 and 1.9 were slotted. As of 2.0, the OpenPGP code is stable development again (no changes that break it are allowed). Most critically, you wherever you previously used GnuPG-1.4, you can use GnuPG-2.0. Seahorse DOES need changing, but it's simply a fix for configure to stop it complaining about a GnuPG version it doesn't know about. It took me just 5 minutes to write up a patch for seahorse's configure. It passes make check, but I can't fully test right now, as my GNOME config is broken. It will be commited later tonight. alonbl: there is one problem you have re-introduced. Please REMOVE usage of capabilities: FORCE --disable-capabilities to be used. They are NOT needed for any kernel newer than 2.6.9 and 2.4.?? (I forget which one), and this lead to the previous problems of a circular reference to kernel sources, and thus we removed the kernel_check stuff in the GnuPG that JUST went stable this last week.
Updating seahorse is fine by me :) Fixing breakage is the primary concern. Upstream will still develop both GnuPG-1 and GnuPG-2. GnuPG-1 seems ideal for server side apps and embedded. Masking GnuPG-2 is one way to go to get that functionality. If there is never a situation where both would be required, then it can serve as a long term solution. Just would seem odd for upstream to state they could co-exist, then not provide that option to users or etc. Either way, it's all pretty old now. So long as seahorse, and any other breakage is addressed. The rest is moot as far as I am concerned :) Note: At one point enigmail (I believe) was said to be broken. Given the amount of deps, I would be curious if other packages have any issues.
(In reply to comment #11) > alonbl: there is one problem you have re-introduced. Please REMOVE usage of > capabilities: FORCE --disable-capabilities to be used. They are NOT needed Done. (In reply to comment #8) > Changing severity to blocker on behalf of Anarchy. Is there any reason leaving this as blocker?
ok, the seahorse patch works. There was a another check inside seahorse-agent that had 1.* hardcoded, and after I modifed that everything works (I created a key, and gave the operations a quick spin). I have commited it to the tree now. The 'modules' that are discussed are the following libraries: libgcrypt, libksba, libgpg-error, libassuan. 1.4 bundled static copies of them, and could not use external variants to build. As other parts of the Gentoo tree brings these packages in as well, having 2.0 as the default (so no 1.4 and 1.9) reduces the overall size of a system.
Grepping the tree quickly, seamonkey (because of enigmail) and enigmail are the only packages that declare a dep on GnuPG-1.4 explictly. I'm not a TB user, so I'd appreciate if somebody could give enigmail a spin to see if it works.
Works with TB 1.5.0.9 here
(In reply to comment #15) > Grepping the tree quickly, seamonkey (because of enigmail) and enigmail are the > only packages that declare a dep on GnuPG-1.4 explictly. They do now? Was not the case two days ago (and yes, works just fine w/ gpg-2)
Re-opening please refer to bug 164523 for any questions as to why. Months have gone by since I first reported this. Please next time let's be more polite to each other, and do more to fix the in tree breakage sooner than later. Thank you very much.
Closing this again, as the seahorse application should support gnupg-2.0 as well now, and if it won't we make it work :)
I have taken this matter upstream. "Seahorse requires an install of GPG 1.x" http://www.gnome.org/projects/seahorse/RELEASE-NOTES-STABLE.txt Slotting is inevitable, it's been avoided for over 2 months now. Upstream has researched it, and made a decision. All other distros provide both, both were designed to work together. Please slot, provide both at the same time as upstream gnupg intended. And end the madness.
Since it's quite obvious this not being followed by either upstream here are some links for further information. I am currently following the seahorse-devel list. Their public archives are borked. Here is a seahorse dev emailing gnupg devel list about gpgme and gnupg2. http://marc.theaimsgroup.com/?l=gnupg-devel&m=117322943507164&w=2 After upstream assume there were no issues, issues were reported and confirmed. http://marc.theaimsgroup.com/?l=gnupg-devel&m=117338885100661&w=2 So it's not just seahorse, and it's not looking like either will be modified for gnupg2. Seahorse upstream has decided to explicitly require gnupg-1.x.
Ugh, someone fix the seahorse nonsense already instead of this completely unproductive noise... Honestly, go use something else if upstream is unable to fix it properly, don't really care.
jacub: Thanks, I am closing this again. wltjr: We won't slot gnupg only because seahorse, please don't open this again for this reason. gpgme works OK as far as I can see, I use it with kmail. If you can produce somekind of scenario where it does not work, I will be happy to work on this as well.
Just for the record... $ pquery --raw --revdep=app-crypt/seahorse $ Nothing depends on this... so, really go use something else if upstream refuses to do anything about this, slotting stuff and creating huge maintenance overhead because one package is retarded doesn't make sense.
ethelle user99 # emerge -NuvDp world These are the packages that would be merged, in order: Calculating world dependencies... done! [ebuild U ] sys-fs/sysfsutils-2.1.0 [1.3.0-r1] 771 kB [ebuild U ] sys-fs/reiserfsprogs-3.6.19-r2 [3.6.19-r1] 398 kB [ebuild U ] sys-devel/gdb-6.7.1 [6.6-r2] USE="nls -test -vanilla" 14,741 kB [ebuild U ] dev-libs/libassuan-1.0.2-r1 [0.6.10] 270 kB [ebuild U ] dev-util/dialog-1.1.20071028 [1.1.20070930] USE="examples nls unicode" 362 kB [ebuild U ] media-libs/giflib-4.1.6 [4.1.4] USE="X -rle" 495 kB [ebuild U ] x11-apps/mesa-progs-7.0.1 [6.5.2] 4,575 kB [ebuild R ] dev-java/sun-jre-bin-1.6.0.03 USE="X alsa nsplugin -odbc%" 0 kB [ebuild U ] x11-misc/xkeyboard-config-1.1 [0.9] 529 kB [ebuild U ] x11-libs/libXpm-3.5.7 [3.5.6] USE="-debug" 350 kB [ebuild U ] x11-apps/xwininfo-1.0.3 [1.0.2] USE="-debug" 97 kB [ebuild U ] media-libs/imlib-1.9.15-r2 [1.9.15-r1] USE="-doc -gtk" 668 kB [ebuild R ] x11-proto/fontcacheproto-0.1.2 USE="(-debug%)" 38 kB [ebuild N ] sys-auth/consolekit-0.2.3 USE="pam -debug" 458 kB [ebuild U ] x11-apps/xrdb-1.0.4 [1.0.3] USE="-debug" 99 kB [ebuild U ] x11-apps/xmodmap-1.0.3 [1.0.2] USE="-debug" 101 kB [ebuild U ] x11-proto/xf86dgaproto-2.0.3 [2.0.2] 43 kB [ebuild U ] x11-apps/xset-1.0.3 [1.0.2] USE="-debug" 101 kB [ebuild U ] x11-apps/xsetroot-1.0.2 [1.0.1] USE="-debug" 87 kB [ebuild U ] x11-apps/xprop-1.0.3 [1.0.2] USE="-debug" 105 kB [ebuild N ] app-crypt/pinentry-0.7.3 USE="caps ncurses qt3 -gtk" 408 kB [ebuild N ] net-misc/curl-7.16.4 USE="ipv6 kerberos ldap ssl -ares -gnutls -idn -nss -test" 1,630 kB [ebuild U ] x11-libs/libXaw-1.0.4 [1.0.3] USE="-debug -xprint" 506 kB [ebuild U ] x11-libs/libXfont-1.3.1 [1.3.0] USE="ipv6 -debug" 552 kB [ebuild U ] x11-libs/libXxf86dga-1.0.2 [1.0.1] USE="-debug" 213 kB [ebuild U ] app-crypt/gnupg-2.0.7 [1.4.7-r1] USE="bzip2 ldap nls -doc% -openct% -pcsc-lite% (-selinux) -smartcard (-bindist%) (-curl%) (-ecc%) (-idea%) (-readline%*) (-static%) (-usb%) (-zlib%*)" LINGUAS="(-ru%)" 3,526 kB [ebuild U ] x11-apps/xmessage-1.0.2 [1.0.1] USE="-debug -xprint" 93 kB [ebuild U ] x11-apps/xclock-1.0.3 [1.0.2] USE="-debug -xprint" 112 kB [ebuild U ] x11-apps/xinit-1.0.5-r1 [1.0.4] USE="hal%* pam%* -debug -minimal" 105 kB [ebuild U ] x11-drivers/xf86-input-mouse-1.2.3 [1.2.2] USE="-debug" 267 kB [blocks B ] <=app-crypt/gnupg-2.0.1 (is blocking app-crypt/gnupg-2.0.7) Total: 30 packages (25 upgrades, 3 new, 2 reinstalls, 1 block), Size of downloads: 31,680 kB ethelle user99 # Ok I am blocked and what's more there is no gnupg-2.0.1 on the system. I need to unmerge what?
emerge -C \<=app-crypt/gnupg-2.0.1; please read the message that portage provides and that you snipped from the output; there's no support forum here.
unfortunately, only =gnupg-1.4* can be compiled statically. so, what's your solution when a user requires a static gpg (e.g. for encrypted root initramfs with cryptsetup/luks) but also gnome (that depends on seahorse which depends on =gpgme-1* which depends on >gnupg-1.9*)?
wschlich: I just forward ported the ebuild changes for USE=static, they work too, decodes/encodes my testcases fine.
(In reply to comment #28) > wschlich: I just forward ported the ebuild changes for USE=static, they work > too, decodes/encodes my testcases fine. Thanks mate, you made my day! :)
Note: smartcard does not work with static, and I remember something else...
I want to use gpg in an initramfs pre-boot environment, but this is very difficult with gpg-2. gpg-1 works well enough, and is recommended by upstream: "Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build and also better portable. In contrast to GnuPG-2 (e.g version 2.0.8) it comes with no support for S/MIME or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict." http://lists.gnupg.org/pipermail/gnupg-announce/2007q4/000266.h Please slot these. They're intended to be installable together on the same system, and providing different behavior than what upstream suggests in this instance seems silly. Currently, I have to uninstall 2, install 1, copy the binary, and then re-install 2.
A saw a request for knowing scenarios where this is needed. dev-php/PEAR-Crypt_GPG - you point it to binary dev-php5/pecl-gnupg - use gpgme With PEAR, in order to do anything with passphrases (ie automate anything) you need to use a version 1 binary. With pecl, it proxies through gpgme so if gpgme is built against version 1 it works else you get the same issue with passphrases. This would be a big help!
In addition to reasons for slotting posted above: In the near future sys-kernel/dracut will come with app-crypt/gnupg-1.4 dependency. There is no way to use GnuPG2 here. We cannot block Dracut users from having GnuPG2, too. The only way is slotting. Therefore I'm reopening the bug to eventually fix it.
Created attachment 271403 [details] gnupg-1.4.11-r1.ebuild SLOT="1"
Created attachment 271405 [details] gnupg-2.0.17-r2.ebuild SLOT="2"
(In reply to comment #32) > A saw a request for knowing scenarios where this is needed. > dev-php/PEAR-Crypt_GPG - you point it to binary > dev-php5/pecl-gnupg - use gpgme > > With PEAR, in order to do anything with passphrases (ie automate anything) you > need to use a version 1 binary. > > With pecl, it proxies through gpgme so if gpgme is built against version 1 it > works else you get the same issue with passphrases. > > This would be a big help! Those PEAR/pecl modules need to be updated for GPG2 then. Passphrase handling changed in GPG2, see how seahorse was fixed as hints on fixing the PHP modules.
I have eventually made Dracut working with GnuPG-2, too. And because there's no benefit of GnuPG-1 over GnuPG-2 even in initramfs, I abandon slotting idea. However if someone see any good reason to slot it, I could do that.
I'm sorry for reviving this topic but doing some development against GnuPG lately, I'd really appreciate being able to install gpg-1 alongside gpg-2. Given the major changes between the two versions, it's hard to write portable applications without actually testing against both. And having to repeatedly downgrade and upgrade is far from pleasant, especially that gpg-1 can't work with homedir of gpg-2 anymore, so I lose ability to commit in the process.
(In reply to Michał Górny from comment #38) > I'm sorry for reviving this topic but doing some development against GnuPG > lately, I'd really appreciate being able to install gpg-1 alongside gpg-2. > Given the major changes between the two versions, it's hard to write > portable applications without actually testing against both. And having to > repeatedly downgrade and upgrade is far from pleasant, especially that gpg-1 > can't work with homedir of gpg-2 anymore, so I lose ability to commit in the > process. 1.4 is closer to being removed from the gentoo tree than being slotted. That said, its not really that difficult to write portable applications againts both if using upstream recommended gpgme. Also the differences between them are clearly documented and easy to foresee (e.g it will fail for ECC)
