Feb 9, 2010, 6:14 AM
Post #2 of 3
(1823 views)
Permalink
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