Raffaele BELARDI posted on Tue, 09 Feb 2010 14:25:26 +0100 as excerpted: > I have a problem importing some pgp keys with gpg 2.x. gpg 1.x might be > able to import these keys. Is it possible to install both gpg 2.x and > gpg 1.x on one system?
gnupg does not appear to be slotted, so it's not normally possible to have both 1.x and 2.x on the same (Gentoo) system, no. However... Do you have FEATURES=buildpkg turned on? If so (and if it was on when you built gnupg), you'll have a binpkg available, so you can simply emerge =gnupg-1.4.10 , and downgrade to the old version (if you're lucky and still have its binpkg around as well, you can add the -K and emerge the binpkg, but probably that's been too long and you've ecleaned it by now). When you're done with the old version, simply emerge -K gnupg and it should upgrade itself back to the new version again, using the binpkg, thus bypassing having to rebuild it. Once you have both binpkgs, you can emerge -K whichever one, switching between them, without having to rebuild, as often as you like. If you don't have FEATURES=buildpkg enabled, do consider doing so as it's well worth the extra space (I run a 4 gig dedicated package partition, 2 gig would work if you eclean it often enough) for the various troubleshooting, nasty trap situations (broken gcc, how do you fix it? just emerge -K an earlier version known to work), and package rebuilding, avoidance. That said... Without FEATURES=buildpkg you can do similar on demand, only using qpkg/ quickpkg (quickpkg is part of portage, qpkg part of portage-utils if you have it merged). Either of these will let you create a binpkg of the currently merged version. You can then do your other version, and use emerge -K to remerge the binpkg you q(uick)pkged up, when you're done. In this case, you'd probably q(uick)pkg the current version and emerge -b (--buildpkg) the old version, thus having both then available to switch between using emerge -K as desired, without further rebuilding. There are however two caveats with q(uick)pkg. First, since it's on-demand, you don't have the binpkg created automatically, so you're less likely to be able to simply emerge -K an old version when a new version isn't working quite as expected. Once you know there's a problem, it's easy enough to q(uickpkg) the current version to get back to it if desired, but you're not as protected against routine upgrade breakage as you're unlikely to have the old versions binpkged since you'd have had to do it manually. Second, binpkging up the current version has security and configuration implications, since it doesn't have the unmodified config to work with, but rather, your running config. Naturally that can cause issues if you share the binpkgs with others, so by default q(uick)pkg will exclude these changed config files from the binpkg it creates, thereby avoiding the problem but leaving the package incomplete in the process, as these altered config files aren't included. There are options to include the altered configs anyway, thus creating a complete package, but of course then you have the security and config issues if you share the package, again. emerge --buildpkg, or emerge with FEATURES=buildpkg, will always be the complete unmodified package. Of course for version switching usage as we're doing here, if the (system) config between the versions differs significantly, q(uick)pkg with the using the option to include the current config would work best anyway, as that way, you'd have automatic handling of the differing configs as well. But I don't think gnupg has enough system config to worry about, it's all per-user config, so that shouldn't be a big issue, regardless (tho you may have to worry about it as your user, just not for the system as a whole). That should help! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
