after successful compilation: how to install safely in a test environment parallet to existing production version
Christian Aistleitner
christian at quelltextlich.at
Sun Aug 5 12:54:42 CEST 2012
Hi Thomas,
On Sun, Aug 05, 2012 at 12:02:32AM +0200, Thomas Gries wrote:
> Is there a way for a safe installation (and later deinstallation)
> of the developer version and tools like gpg-agent
> */
> in parallel to the existing gpg installation on that server ?
> /*
> If yes, how ?
Yes, it's easily possible. Autotools to the rescue :-)
As with any autotools package (GnuPG etc are such packages), the
--prefix option does what you want.
Here's what I did on a GNU/Linux system. I configured the git head of
GnuPG using
./configure [...] --prefix=/home/christian/gnupg-prefix [...]
Afterwards build GnuPG. Upon "make install" the files get installed
into the prefix directory, which resolves to subdirectories of
/home/christian/gnupg-prefix in the above example. So for example the
gpg2 binary can be found in /home/christian/gnupg-prefix/bin/gpg2.
So on my system, I have the distribution provided GnuPG in
/usr/bin/gpg2, and the git head's build in
/home/christian/gnupg-prefix/bin/gpg2.
My email client still uses /usr/bin/gpg2. For experiments with the git
head's build, I prepend /home/christian/gnupg-prefix/bin to the path
in a shell. Then within this shell, gpg2 refers to the git head's
gpg2. Thereby you can use both variants in parallel, choose within the
shell which variant you want to use, while the mail client still uses
the distribution provided, known good gpg2.
But be aware of which gpg-agent etc you are using for which gpg2 :-)
As for uninstalling, just issue "make uninstall" in the directory,
where you issued "make install" in (Without un- or reconfiguring
within this directory). If you used the --prefix option during
configuration, "make uninstall" will only remove the files it
installed in the prefix directory.
Now for the fun part, as the above only treats GnuPG itself and does
not yet cover libraries. You probably also want to use git head's
libassuan etc. In this case, use the --prefix option for all the
packages installed by hand. But be aware that when installing
libassuan in a prefix directory, linking gnupg need not pick the
prefix version automatically. Therefore, GnuPG comes with additional
--with-libassuan-prefix and --with-npth-prefix options. Those options
allow you to specify which libassuan, ... you want GnuPG to link
against.
So you could decouple the prefixes of all used libraries into separate
directories, or throw all the libraries related to GnuPG's git head
into the same prefix. The latter is what I chose, as it makes setting
up the dynamic linker easier.
Depending how you choose to link GnuPG, you might end up with a git's
head gpg2 trying to (at runtime) use the libassuan provided by your
distribution. You can check using the ldd utility.
For example:
ldd /home/christian/gnupg-prefix/bin/gpg2
[...]
libassuan.so.0 => /usr/lib64/libassuan.so.0 [...]
[...]
Note that libassuan.so.0 would be met by /usr/lib64/libassuan.so.0,
which is not the prefixed variant. So let's set LD_LIBRARY_PATH in the
shell that should get used for the GnuPG's git head:
export LD_LIBRARY_PATH="/home/christian/gnupg-prefix/lib:$LD_LIBRARY_PATH"
and check again
ldd /home/christian/gnupg-prefix/bin/gpg2
[...]
libassuan.so.0 => /home/christian/gnupg-prefix/lib/libassuan.so.0 [...]
[...]
Now, git's head libassuan get's used as well.
So finally you have two parallel, completely decoupled installs of GnuPG:
1. The one coming straight from your GNU/Linux distribution, and
2. Git's head build.
Both of them are usable. In a fresh, unmodified environment, you'll
just use the distribution provided variant. If you want to use the
git's head variant, just set the PATH and LD_LIBRARY_PATH environment
(and take care of gpg-agent ;) ) and you're using git's head GnuPG in
this shell.
Be aware, that there are other options as well that you may want to
setup, to get a more hassle free dual GnuPG setup: E.g.:
--with-agent-pgm or --with-pinentry-pgm
To get a list of available options along with a description, use the
"--help" parameter of the ./configure script of each of the packages.
All the best,
Christian
P.S.: As for the problem
> I found gpg2 in the subdirectory /g10/gpg2 of the compiled sources
> [...]
> /usr/local/bin/gpg-agent: probably not installed
This hints towards the fact that you did not set a prefix when running
configure (Running ./configure by hand without any prefix option
typically defaults to a prefix of '/usr/local') and that you did not
install your compiled variant, which is fair enough.
If you want to avoid to install on your machine (Note however, that
the above description works without requiring administrative access on
typical distribution settings. So you can work as plain user and
install under your home directory, to avoid shooting yourself in the
foot), the gpg-agent executable is in the "agent" subdirectory of your
git checkout (after compiling GnuPG that is).
--
---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
Companies' registry: 360296y in Linz
Christian Aistleitner
Gruendbergstrasze 65a Email: christian at quelltextlich.at
4040 Linz, Austria Phone: +43 732 / 26 95 63
Fax: +43 732 / 26 95 63
Homepage: http://quelltextlich.at/
---------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: </pipermail/attachments/20120805/1a64da53/attachment.pgp>
More information about the Gnupg-devel
mailing list