Usage of configure during non-standard installation

FranekW · 05-22-2017, 04:22 AM

I am a newbie when it comes to Linux but not completely lost

I installed CentOS 7 a couple of weeks ago because this is what I have at uni. I have already managed to install a couple of applications, created a few custom icons in my Show Application but I am currently struggling to install GnuGP 2.1.12. Normally I would go for `yum install <app>` but this and a lot of other applications on CentOS 7 are outdated, e.g. git 1.8.x.

Installing GnuGP 2.1.21 (link) from sources requires to handle a bunch of dependencies which are also available on the same website. I guess if I used the default sequence below to each of the dependencies:

Code:

./configre
make
sudo make install

I would be fine but I don't really want to mess with /usr/*/bin folder which I think is maintained by yum.

I have already read how to install application (here) but I would like to choose a custom folders for that, e.g. /opt. How should I proceed. Aforementioned dependencies will most likely be installed as libraries, include files etc. which GnuGP needs to function. I would like all of them to be installed in custom folders, somewhere away from system folders. Is it possible? If yes, would it be really hard to do? I have noticed ./configure accepts a lot of options, such as --prefix but I guess I need more than that, especially when it comes to locate custom libraries/extra files etc.

Thanks.

rtmistler · 05-22-2017, 07:21 AM

One suggested step by their documentation is that you should run autogen.sh:

Code:

./autogen.sh

Based on the outcome of that it will recommend possible arguments for the ./configure step.

I don't understand your concerns about the /usr/bin, /usr/sbin tree, this is what it is there for. Installing the formal binaries for common applications.

When you perform yvm install <app>, it usually places the executable images in any of: /bin, /sbin, /usr/bin, or /usr/sbin

FranekW · 05-22-2017, 08:18 AM

Quote:

Originally Posted by rtmistler

I don't understand your concerns about the /usr/bin, /usr/sbin tree, this is what it is there for. Installing the formal binaries for common applications.

When you perform yvm install <app>, it usually places the executable images in any of: /bin, /sbin, /usr/bin, or /usr/sbin

I am afraid that if something wrong happens and I have already used default system folders for dependencies, I won't be able to recover from it and revert back where I was. For instance, CentOS has gpg2 already installed via yum install gpg2, which is an old version and use deprecated system of managing security keys. If I perform this installation using default system folders, I will very likely overwrite something that is already installed, e.g. original files regarding gpg2.

I don't know how to check things like this and do any precautions in case things have gone wrong. I would probably have to reinstall the system.

rtmistler · 05-22-2017, 08:34 AM

You can uninstall the new one and then re-install the former one using the yvm method. What you can do in the forward direction, you can do in the reverse direction.

BW-userx · 05-22-2017, 08:45 AM

as far as backing off and resetting to where it was before you ran the

Code:

./configure
make
#make install

if that configure is not setup with an uninstall script within its bundle then it is manually removing of same said item. if all it did was add an executable within your bin then just delete it. if it installed much more than that then you have to track it down and delete it manually. this should not bother your system as long as other "apps" are not depending on anything it is giving.

if by chance it was, then just re-install it the same way you did the first time. that should fix it.

Where you are wanting to put everything you do using ./configure into /opt just to play it safe is a can do thing. then you're going to have to learn how to make your system look in there every time it is wanting to use something that usually goes into one of the bins or else where within the system which could get complected but it is still a possibility.

with Slack or Void Linux one just makes a script then run it so that system then can take care of it. It knows where it is at if one wants to upgrade or remove same said item then simply use that 'custom' script to do so. Makes life using Linux/GNU a bit easier when installing outside of the repo.

FranekW · 05-22-2017, 11:08 AM

Are you sure I can install GnuGP using default options? I just want to point out that GPG2 in CentOS seems a special protected application because YUM somehow uses for its own purpose. I am still not convinced if I should do it!

BTW, thanks for your comments

BW-userx · 05-22-2017, 11:23 AM

what is the worst case scenario if you install it and it does a ka pow on ya?
Are you able to recover from this worst case scenario?
if yes, Then what was so bad about it that it stopped you from finding out first hand?

DavidMcCann · 05-22-2017, 11:42 AM

Stop! Right now!

The point about enterprise-class distros is that they go for tried-and-tested rather than bleeding-edge. If Red Hat (and that's what your CentOS is) gives you a particular version of GnuPG, that is proof enough that the version in question is adequate. "Updating" can (and probably will) break things. If a program has a security fault, then Red Hat back-port the solution, incorporating the patch issued for the newer version into the one they use.

On the general question of adding things to CentOS, read this
http://wiki.centos.org/AdditionalResources/Repositories
and this
http://wiki.centos.org/PackageManagement/Yum/Priorities
If you obey the rules, then you can install extra software safely; if you don't, then the only guarantee is that if it breaks you get to keep the pieces.

rtmistler · 05-22-2017, 11:43 AM

Quote:

Originally Posted by BW-userx

what is the worst case scenario if you install it and it does a ka pow on ya?
Are you able to recover from this worst case scenario?
if yes, Then what was so bad about it that it stopped you from finding out first hand?

And this is also not so non-standard. It's not like you're trying to install 10 year old software into an updated OS, you're just trying to install a new experimental release of this software, I believe.

A "data part" system backup is a good idea.

I also feel that one worst is that a few things need to be fixed, rather than the entire system be messed up to be unusable.

BW-userx · 05-22-2017, 11:47 AM

Quote:

Originally Posted by rtmistler

And this is also not so non-standard. It's not like you're trying to install 10 year old software into an updated OS, you're just trying to install a new experimental release of this software, I believe.

A "data part" system backup is a good idea.

I also feel that one worst is that a few things need to be fixed, rather than the entire system be messed up to be unusable.

I never told him to DO IT --
just gave him something to think about. He then needs to weigh out everything before making that decision.

worst case then is re-install lessened learned. carry on smartly.

sundialsvcs · 05-22-2017, 11:48 AM

If you want to experiment with other versions of software, the most-important consideration is your target. Do not allow the configure/make scripts to target the "usual" system-level directories. Do not invoke "root" privileges. Do not do anything that might require them.

You should, instead, target a private directory that is intended for such purposes, such as /usr/local. Or, put it somewhere else altogether. The distro's packaging subsystem will be unaware (and, unconcerned) of its existence. It's a good idea to place it somewhere such that intended users of the package must add the location to their $PATH, e.g. by adding a statement to their .bash_profile.

FranekW · 05-22-2017, 03:44 PM

Hi,

I have installed GnuPG 2.1.12 and it works. Based on a script made by someone else, I have made the one below. Doing it manually would be very easy to make mistake, which I have probably made before :/ Now, everything has been installed and works ok. I have one only problem. I tried to verify signature files but I have got errors and I had to comment that block. Do you know why I have got errors?

Thanks

The code.

Code:

#!/bin/bash
 
CD=$(pwd)
 
mkdir --parents /opt/homeusr/gpg-install && \
cd /opt/homeusr/gpg-install && \
 
wget -c https://www.gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.21.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.21.tar.bz2.sig && \
wget -c https://www.gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.27.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/libgpg-error/libgpg-error-1.27.tar.bz2.sig && \
wget -c https://www.gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.6.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.6.tar.bz2.sig && \
wget -c https://www.gnupg.org/ftp/gcrypt/libassuan/libassuan-2.4.3.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/libassuan/libassuan-2.4.3.tar.bz2.sig && \
wget -c https://www.gnupg.org/ftp/gcrypt/libksba/libksba-1.3.5.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/libksba/libksba-1.3.5.tar.bz2.sig && \
wget -c https://www.gnupg.org/ftp/gcrypt/npth/npth-1.4.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/npth/npth-1.4.tar.bz2.sig && \
wget -c https://www.gnupg.org/ftp/gcrypt/ntbtls/ntbtls-0.1.1.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/ntbtls/ntbtls-0.1.1.tar.bz2.sig && \
wget -c https://www.gnupg.org/ftp/gcrypt/pinentry/pinentry-1.0.0.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/pinentry/pinentry-1.0.0.tar.bz2.sig && \
wget -c https://www.gnupg.org/ftp/gcrypt/gpgme/gpgme-1.9.0.tar.bz2 && \
wget -c https://www.gnupg.org/ftp/gcrypt/gpgme/gpgme-1.9.0.tar.bz2.sig && \
wget -c ftp://ftp.gnu.org/gnu/ncurses/ncurses-6.0.tar.gz
wget -c ftp://ftp.gnu.org/gnu/ncurses/ncurses-6.0.tar.gz.sig
 
#gpg --verify libgpg-error-1.27.tar.bz2.sig && \
#gpg --verify libgcrypt-1.7.6.tar.bz2.sig && \
#gpg --verify libassuan-2.4.3.tar.bz2.sig && \
#gpg --verify libksba-1.3.5.tar.bz2.sig && \
#gpg --verify npth-1.4.tar.bz2.sig && \
#gpg --verify ntbtls-0.1.1.tar.bz2.sig && \
#gpg --verify pinentry-1.0.0.tar.bz2.sig && \
#gpg --verify gpgme-1.9.0.tar.bz2.sig && \
#gpg --verify gnupg-2.1.21.tar.bz2.sig && \
#gpg --verify ncurses-6.0.tar.gz.sig && \
 
tar -xjf libgpg-error-1.27.tar.bz2 && \
tar -xjf libgcrypt-1.7.6.tar.bz2 && \
tar -xjf libassuan-2.4.3.tar.bz2 && \
tar -xjf libksba-1.3.5.tar.bz2 && \
tar -xjf npth-1.4.tar.bz2 && \
tar -xjf ntbtls-0.1.1.tar.bz2 && \
tar -xzf ncurses-6.0.tar.gz && \
tar -xjf pinentry-1.0.0.tar.bz2 && \
tar -xjf gpgme-1.9.0.tar.bz2 && \
tar -xjf gnupg-2.1.21.tar.bz2 && \
 
rm libgpg-error-1.27.tar.bz2 && \
rm libgpg-error-1.27.tar.bz2.sig && \
rm libgcrypt-1.7.6.tar.bz2 && \
rm libgcrypt-1.7.6.tar.bz2.sig && \
rm libassuan-2.4.3.tar.bz2 && \
rm libassuan-2.4.3.tar.bz2.sig && \
rm libksba-1.3.5.tar.bz2 && \
rm libksba-1.3.5.tar.bz2.sig && \
rm npth-1.4.tar.bz2 && \
rm npth-1.4.tar.bz2.sig && \
rm ntbtls-0.1.1.tar.bz2 && \
rm ntbtls-0.1.1.tar.bz2.sig && \
rm pinentry-1.0.0.tar.bz2 && \
rm pinentry-1.0.0.tar.bz2.sig && \
rm gpgme-1.9.0.tar.bz2 && \
rm gpgme-1.9.0.tar.bz2.sig && \
rm gnupg-2.1.21.tar.bz2 && \
rm gnupg-2.1.21.tar.bz2.sig && \
rm ncurses-6.0.tar.gz && \
rm ncurses-6.0.tar.gz.sig && \
 
cd libgpg-error-1.27 && ./configure && make && make install && cd ../ && \
cd libgcrypt-1.7.6 && ./configure && make && make install && cd ../ && \
cd libassuan-2.4.3 && ./configure && make && make install && cd ../ && \
cd libksba-1.3.5 && ./configure && make && make install && cd ../ && \
cd npth-1.4 && ./configure && make && make install && cd ../ && \
cd ntbtls-0.1.1 && ./configure && make && make install && cd ../ && \
cd ncurses-6.0 && ./configure && make && make install && cd ../ && \
cd pinentry-1.0.0 && ./configure --enable-pinentry-curses --disable-pinentry-qt4 && make && make install && cd ../ && \
cd gpgme-1.9.0 && ./configure && make && make install && cd ../ && \
cd gnupg-2.1.21 && ./configure && make && make install && \
 
echo "/usr/local/lib" > /etc/ld.so.conf.d/gpg2.conf && ldconfig -v && \
 
cd $CD
 
echo "Complete !!!"