[gentoo-amd64] Re: multiple versions of gpg

[Duncan]

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