Installing software with linux

Installing Software on Linux¶

One of the most difficult things to get used to in the Linux world is installing new software packages. In the world of Windows, every program comes with a Setup.exe program that asks you some very easy questions and takes care of the job for you. While Linux software can be almost that easy to install, you will sometimes find software that seems to fight every step of the way. I can’t cover all the problems you might run into, but I’ll try to give you the basics and a few pointers to help get you over the rough spots.

Software tends to come in “packages”. In the Windows world a package is a Setup.exe or a program.zip file. On a Mac a package is a program.dmg or a program.sit file. In the Linux world, there are several kinds of packages, and each distribution has its own preferred package format.

The standard Linux package format (according to the Linux Standard Base) is RPM. RPM is a packaging system originally developed by Red Hat and widely used in the Linux community. Distributions using it include Fedora, Mandriva, Red Hat (naturally), and SUSE. An RPM package file normally will be named something like program-version-other.rpm

Another popular package format is DEB, the Debian software package. Debian packages and the Advanced Packaging Tool (APT) were the first to introduce several advanced features that are now common, such as automatic dependency resolution and signed packages. Debian packages are used by Debian GNU/Linux (naturally), and distributions based on it, including Ubuntu, Knoppix, and Mepis. A Debian package file normally will be named something like program-version-other.deb

Remember, you will need to become SuperUser to install software.

Debian, Ubuntu: APT¶

There is a broad array of tools for working with DEB packages, but the one you will commonly use is apt-get , arguably the easiest of Linux package management tools. apt-get is so easy because it not only keeps track of what packages are installed, but also what other packages are available. It will even download them from the Internet for you (if properly configured).

To remove software is just as easy.

Although the repositories that contain installable packages might live on the Internet or on a disc somewhere, APT keeps a local database on your hard drive with a list of all available packages and where to find them. This database needs to be explicitly updated. To update the APT database:

A common idiom is to update your package database, and then upgrade all the packages that have patches or security updates to install. The following command will do this all at once.

For a more indepth apt-get tutorial and other resources, see Managing Software with APT and dpkg .

Fedora, Red Hat: yum В¶

yum does for RPM packages roughly what apt-get does for Debian packages. Like apt-get , yum can download and install packages from a configured repository.

To remove software is just as easy.

yum does not keep a local copy of your package database by default, so normally there is no need to update it. To install all available security patches and bug fixes, use this command:

You can also explicitly update a single package with:

For a more indepth yum tutorial and other resources, see Managing Software with yum and rpm .

Mandriva: urpm В¶

Mandriva Linux (formerly Mandrake and Connectiva) has a toolset similar to APT called urpmi . To install software:

To remove software:

To update the local package database:

To install security updates and bug fixes:

For a more indepth yum tutorial and other resources, see Managing Software with urpm .

Tar Balls¶

No, this is not a naughty term! A tar ball is a (usually compressed) archive of files, similar to a Zip file on Windows or a Sit on the Mac. Tar balls come in files that end in .tar , .tar.gz , .tgz , or something along these lines. To unpack a tar ball, use this command.

The parameters are x to extract files, z to filter through gzip for decompression (leave this off if the file does not have a gz extension), v for verbose mode so you can tell what’s going on, f indicating there will be a filename to follow. You may want to create an alias called “untar” that feeds in these options if you have a hard time remembering command line options as I do.

This command will not install the software, it will only extract the archived files. It is your job then to find the README file or INSTALL file and read its instructions for installation. If the archive contains binaries there will usually be a setup script (often called install.sh ) that you must execute as SuperUser .

Very often, software delivered in tar balls is not in executable form, but in source code, which must first be compiled before it can be installed. For more details on this, see Installing Software from Source Code .

Other Systems¶

Some other Linux distributions have their own way of managing packages, notably SUSE. SUSE uses RPM as its native package format, but has its own high level tool to manage system software installation.

SUSE Linux uses a tool called yast (which allegedly is an acronym for Yet Another Setup Tool) to perform all kinds of system administration tasks, including installing software. Having no experience with it, I cannot give you more details. man yast for help.

Источник

How to Install Software on Linux

So you’ve made the switch to Linux. Or you’re thinking of making the switch. But you have questions that might be stopping you from fully diving in. One of the biggest concerns most new users have is, “What software is available and how do I install it?”

It’s a reasonable question. Why? For the longest time, Linux suffered from a stigma that applications were scarce, and that the few available options were a challenge to install. I remember, back in the early days, having to compile software from source packages—which would lead to a seemingly endless circle of missing dependencies. It was frustrating, but doable. That frustration, however, turned a lot of people away from Linux.

Fortunately, those days are long since past, and installing any of the available software titles (of which there are many) on Linux is no longer such a headache.

How to Get Started with the Linux Operating System

What operating system do you use? For some, that question may as well be posed in Latin or…

Before we get into the how-tos of actually installing software on Linux, there is one very important concept to understand:

Package managers

This is one of those topics that tends to confound most new Linux users. A package manager is a sub-system on Linux that, as the title says, manages the packages (software) on your computer. It’s a crucial component of Linux, in that it keeps track of everything installed; downloads packages; ensures all packages are installed in a common location; helps to upgrade packages; resolves dependencies; and keeps users from having to install from source code.

The biggest point of confusion is that there are numerous package managers available, but only one can be used on a distribution. In fact, distributions are differentiated, primarily, on which package manager they choose. For example: Debian and Ubuntu (and its derivatives) use apt; Red Hat Enterprise Linux , CentOS , and Fedora use yum; SUSE and openSUSE use zypper; and Arch Linux uses pacman. There are more package managers out there, but this is a good place to start.

Each package manager works with a different file type. For example, apt works with .deb files and yum and zypper work with .rpm files. The apt package manager cannot install .rpm files and neither yum or zypper can install .deb files. To make matters even more confusing, Ubuntu (and its derivatives) uses the dpkg command for installing local .deb files, and Red Hat (and its derivatives) use the rpm command to install local .rpm files.

Install a Windowed GNU/Linux Environment On Any Android Device With This Guide

Android’s designed largely for mobile users, but since it has Linux at its core, it can work with a

Confused yet? Don’t worry, it’s actually much easier than that.

Most package managers have GUI front ends. These front ends are similar to the Apple App Store. It should be no surprise that there are numerous such GUI front ends available. The good news here is that most of them are similarly titled (such as GNOME Software, Ubuntu Software, Elementary AppCenter). These app stores allow you to easily search for a software title and install it with the click of a button (more on this in a bit).

There is one other issue with package managers: repositories. Repositories are a key aspect of package managers, but for new users the concept can add yet another level of confusion we don’t want. For a quick overview, however, consider this: Out of the box you only have a certain selection of software titles available. That selection is dictated by the repositories that are configured. There are numerous third-party repositories you can add to the system. Once added, you can then install any software titles associated with those third-party repositories. Software repositories can be added either from a GUI tool or the command line.

In any case, repositories are an issue for a different day, and not necessary to understand for the type of software downloads discussed in this article.

Installing a downloaded file

I know, I know… I said one of the benefits of modern Linux operating systems is that you don’t need to install from a downloaded file. That being said, I want to start here. Why? There may be times when you find a piece of software not available in your distribution’s “app store.” When that occurs, you’ll need to know how to install that application manually. I will say that, for everyday, average use, it’s a rare occasion that you’ll need to do this. And even if you never do install using this method, at least you’ll have a very basic understanding of how it works.

Here, we’ll demonstrate using the latest release of Ubuntu Linux (as of this writing, 17.10). Most package managers install in similar fashion (with slight variations on the commands used). Let’s say you want to install the Google Chrome browser on Ubuntu. You won’t find this particular browser in the Ubuntu Software tool. To install it from the command line, you must download the correct file. As stated earlier, the correct file for Ubuntu will be a .deb file. So point your browser to the Chrome download page and click the Download Chrome button. The good news here is that your browser will be detected and the Chrome download page will know which file you need. Click the ACCEPT AND INSTALL button and a new window will appear, giving you two options (see below).

You can either save the file to your hard drive (and then install via the command line), or open the file with the Software Installer. It is important to understand that not every distribution includes the latter. If you do not get the Open with option, then you’ll have to install from the command line.

Let’s first use the Open with option. Make sure Software Install (default) is selected and click OK. The file will download and then Ubuntu Software will open, giving you the option to install (see below).

Click Install and you will be prompted for your user password. The installation will complete and Chrome is ready to use. You can close the Ubuntu Software tool and open Chrome from the Dash.

But what if you don’t get the option to install with the GUI tool? Then you have to select the Save File and run the installation from the command line. Don’t worry, it’s not that hard. Here are the steps to install the latest release of Chrome, on Ubuntu Linux, from the command line:

1. Click on the square of dots at the bottom of the desktop
2. When the Dash opens, type terminal
3. Change into the Downloads directory with the command cd

/Downloads

Install Chrome with the command sudo dpkg -i google-chrome*.deb

When prompted (see below), type your user password and hit Enter on your keyboard

Allow the installation to complete

Installing from the GUI

This is where things get very easy. To install from your distribution’s GUI, you only need open up the tool, search for the software you want, and click Install. Say, for instance, you want to install the GIMP Image editor . To do that, open Ubuntu Software and type gimp in the search bar. When the results appear, click on the GIMP entry, click the Install button (see below), and (when prompted) type your user password. Wait for the installation to complete and your new software is ready to be opened and used.

Bottom line: it’s all easier than it seems

Installing software on Linux isn’t nearly as hard as you might have thought. Yes, there may be the rare occasion when you need to install something from the command line, but even that isn’t much of a challenge. Besides, chances are, you’ll never have to install software outside of the GUI front end.

Do remember, if you use a distribution other than Ubuntu (or its derivatives), you’ll want to do a quick bit of googling to make sure you understand the differences between the apt package manager and the one used on your desktop.

Источник

How to Install Software from Source Code… and Remove it Afterwards

Last updated August 17, 2020 By Sylvain Leroux 58 Comments

Brief: This detailed guide explains how to install a program from source code in Linux and how to remove the software installed from the source code.

One of the greatest strength of your Linux distribution is its package manager and the associated software repository. With them, you have all the necessary tools and resources to download and install new software on your computer in a completely automated manner.

But despite all their efforts, the package maintainers cannot handle each and every use cases. Nor can they package all the software available out there. So there are still situations where you will have to compile and install new software by yourself. As for me, the most common reason, by far, I have to compile some software is when I need to run a very specific version, or modify the source code by the use of some fancy compilation options.

If your needs belong to the latter category, chances are you already know what to do. But, for the vast majority of Linux users, compiling and installing software from the source code for the first time might look like an initiation ceremony: somewhat frightening; but with the promise of entering a new world of possibilities and a place of prestige in a privileged community.

A. Installing software from source code in Linux

And that’s exactly what we will do here. For the purpose of this article, let’s say I need to install NodeJS 8.1.1 on my system. That version exactly. A version which is not available from the Debian repository:

Now, installing NodeJs on Ubuntu or Debian is pretty simple if you do it with the package manager. But let’s do it via the source code.

Step 1: Getting the source code from GitHub

Like many open-source projects, the sources of NodeJS can be found on GitHub: https://github.com/nodejs/node

So, let’s go directly there.

If you’re not familiar with GitHub, git or any other version control system worth mentioning the repository contains the current source for the software, as well as a history of all the modifications made through the years to that software. Eventually up to the very first line written for that project. For the developers, keeping that history has many advantages. For us today, the main one is we will be able to get the sources from for the project as they were at any given point in time. More precisely, I will be able to get the sources as they were when the 8.1.1 version I want was released. Even if there were many modifications since then.

On GitHub, you can use the “branch” button to navigate between different versions of the software. “Branch” and “tags” are somewhat related concepts in Git. Basically, the developers create “branch” and “tags” to keep track of important events in the project history, like when they start working on a new feature or when they publish a release. I will not go into the details here, all you need to know is I’m looking for the version tagged “v8.1.1”

After having chosen on the “v8.1.1” tag, the page is refreshed, the most obvious change being the tag now appears as part of the URL. In addition, you will notice the file change date are different too. The source tree you are now seeing is the one that existed at the time the v8.1.1 tag was created. In some sense, you can think of a version control tool like git as a time travel machine, allowing you to go back and forth into a project history.

At this point, we can download the sources of NodeJS 8.1.1. You can’t miss the big blue button suggesting to download the ZIP archive of the project. As for me, I will download and extract the ZIP from the command line for the sake of the explanation. But if you prefer using a GUI tool, don’t hesitate to do that instead:

Downloading the ZIP archive works great. But if you want to do it “like a pro”, I would suggest using directly the git tool to download the sources. It is not complicated at all— and it will be a nice first contact with a tool you will often encounter:

By the way, if you have an issue, just consider the first part of this article as a general introduction. Later I have more detailed explanations for Debian- and RedHat-based distributions in order to help you troubleshoot common issues.

Anyway, whenever you downloaded the source using git or as a ZIP archive, you should now have exactly the same source files in the current directory:

Step 2: Understanding the Build System of the program

We usually talk about “compiling the sources”, but the compilation is only one of the phases required to produce a working software from its source. A build system is a set of tool and practices used to automate and articulate those different tasks in order to build entirely the software just by issuing few commands.

If the concept is simple, the reality is somewhat more complicated. Because different projects or programming language may have different requirements. Or because of the programmer’s tastes. Or the supported platforms. Or for historical reason. Or… or.. there is an almost endless list of reasons to choose or create another build system. All that to say there are many different solutions used out there.

NodeJS uses a GNU-style build system, it is a popular choice in the open source community and once again, a good way to start your journey.

Writing and tuning a build system is a pretty complex task, but for the “end user”, GNU-style build systems ease the task by using two tools: configure and make .

The configure file is a project-specific script that will check the destination system configuration and available feature in order to ensure the project can be built, eventually dealing with the specificities of the current platform.

An important part of a typical configure job is to build the Makefile . That is the file containing the instructions required to effectively build the project.

The make tool, on the other hand, is a POSIX tool available on any Unix-like system. It will read the project-specific Makefile and perform the required operations to build and install your program.

But, as always in the Linux world, you still have some leniency in customising the build to your specific needs .

The configure -help command will show you all the available configuration options. Once again, this is very project-specific. And to be honest, it is sometimes necessary to dig into the project before fully understanding the meaning of each and every configure option.

But there is at least one standard GNU Autotools option that you must know: the —prefix option. This has to do with the file system hierarchy and the place your software will be installed.

Step 3: The FHS

The Linux file system hierarchy on a typical distribution mostly comply with the Filesystem Hierarchy Standard (FHS)

That standard explains the purpose of the various directories of your system: /usr , /tmp , /var and so on.

When using the GNU Autotools— and most other build systems— the default installation location for your new software will be /usr/local . Which is a good choice as according to the FSH “The /usr/local hierarchy is for use by the system administrator when installing software locally? It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.”

The /usr/local hierarchy somehow replicates the root directory, and you will find there /usr/local/bin for the executable programs, /usr/local/lib for the libraries, /usr/local/share for architecture independent files and so on.

The only issue when using the /usr/local tree for custom software installation is the files for all your software will be mixed there. Especially, after having installed a couple of software, it will be hard to track to which file exactly of /usr/local/bin and /usr/local/lib belongs to which software. That will not cause any issue to the system though. After all, /usr/bin is just about the same mess. But that will become an issue the day you will want to remove a manually installed software.

To solve that issue, I usually prefer installing custom software in the /opt sub-tree instead. Once again, to quote the FHS:

_”/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/

directory tree, where

is a name that describes the software package and

is the provider’s LANANA registered name.”_

So we will create a sub-directory of /opt specifically for our custom NodeJS installation. And if someday I want to remove that software, I will simply have to remove that directory:

Anything but “ok” after the make command has completed would mean there was an error during the build process. As we ran a parallel build because of the -j option, it is not always easy to retrieve the error message given the large volume of output produced by the build system.

In the case of an issue, just restart make , but without the -j option this time. And the error should appear near the end of the output:

Finally, once the compilation has gone to the end, you can install your software to its location by running the command:

B. What if things go wrong while installing from source code?

What I’ve explained above is mostly what you can see on the “build instruction” page of a well-documented project. But given this article goal is to let you compile your first software from sources, it might worth taking the time to investigate some common issues. So, I will do the whole procedure again, but this time from a fresh and minimal Debian 9.0 and CentOS 7.0 systems so you can see the errors I encountered and how I solved them.

From Debian 9.0 “Stretch”

This problem is quite easy to diagnosis and solve. Just install the git package:

No problem here.

Obviously, to compile a project, you need a compiler. NodeJS being written using the C++ language, we need a C++ compiler. Here I will install `g++`, the GNU C++ compiler for that purpose:

One other missing tool. Same symptoms. Same solution:

Please notice: I’ve installed the various tools one by one to show how to diagnosis the compilation issues and to show you the typical solution to solve those issues. But if you search for more information about the topic or read other tutorials, you will discover that most distributions have “meta-packages” acting as an umbrella to install some or all the typical tools used for compiling a software. On Debian-based systems, you will probably encounter the build-essentials package for that purpose. And on Red-Hat-based distributions, that will be the “Development Tools” group.

From CentOS 7.0

Command not found? Just install it using the yum package manager:

You guess it: NodeJS is written using the C++ language, but my system lacks the corresponding compiler. Yum to the rescue. As I’m not a regular CentOS user, I actually had to search on the Internet the exact name of the package containing the g++ compiler. Leading me to that page: https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

C. Making changes to the software installed from source code

You may install software from the source because you need a very specific version not available in your distribution repository, or because you want to modify the program to fix a bug or add a feature. After all, open-source is all about making modifications. So, I will take this opportunity to give you a taste of the power you have at hand now that you are able to compile your own software.

Here, we will make a minor change to the sources of NodeJS. And we will see if our change will be incorporated into the compiled version of the software:

Open the file node/src/node.cc in your favorite text editor (vim, nano, gedit, … ). And try to locate that fragment of code:

It is around line 3830 of the file. Then modify the line containing printf to match that one instead:

Then head back to your terminal. Before going further— and to give you some more insight of the power behind git— you can check if you’ve modified the right file:

You should see a “-” (minus sign) before the line as it was before you changed it. And a “+” (plus sign) before the line after your changes.

It is now time to recompile and re-install your software:

This times, the only reason it might fail is that you’ve made a typo while changing the code. If this is the case, re-open the node/src/node.cc file in your text editor and fix the mistake.

Once you’ve managed to compile and install that new modified NodeJS version, you will be able to check if your modifications were actually incorporated into the software:

Congratulations! You’ve made your first change to an open-source program!

D. Let the shell locate our custom build software

You may have noticed that I’ve always launched my newly compiled NodeJS software by specifying the absolute path to the binary file.

It works. But this is annoying, to say the least. There are actually two common ways of fixing that.

There are actually two common ways of fixing the annoying problem of specifying the absolute path to the binary files,
but to understand them you must first know that your shell locates the executable files by looking for them only in the directories specified by the PATH environment variable.

Here, on that Debian system, if you do not specify explicitly any directory as part of a command name, the shell will first look for the executable programs in /usr/local/bin , then if not found into /usr/bin , then if not found into /bin then if not found into /usr/local/games then if not found into /usr/games , then if not found … the shell will report an error “command not found”.

Given that, we have two way to make a command accessible to the shell: by adding it to one of the already configured PATH directories. Or by adding the directory containing our executable file to the PATH .

Adding a link from /usr/local/bin

Just copying the node binary executable from /opt/node/bin to /usr/local/bin would be a bad idea since by doing so, the executable program would no longer be able to locate the other required components belonging to /opt/node/ (it’s a common practice for software to locate its resource files relative to its own location).

So, the traditional way of doing that is by using a symbolic link:

This is a simple and effective solution, especially if a software package is made of just few well known executable programs— since you have to create a symbolic link for each and every user-invokable command. For example, if you’re familiar with NodeJS, you know the npm companion application I should symlink from /usr/local/bin too. But I let that to you as an exercise.

Modifying the PATH

First, if you tried the preceding solution, remove the node symbolic link created previously to start from a clear state:

And now, here is the magic command to change your PATH :

Simply said, I replaced the content of the PATH environment variable by its previous content, but prefixed by /opt/node/bin . So, as you can imagine it now, the shell will look first into the /opt/node/bin directory for executable programs. We can confirm that using the which command:

Whereas the “link” solution is permanent as soon as you’ve created the symbolic link into /usr/local/bin , the PATH change is effective only into the current shell. I will leave you to do some research on how to make changes in the PATH permanents. As a hint, it has to do with your “profile”. If you find the solution, don’t hesitate to share that with the other readers by using the comment section below!

E. How to remove that newly installed software from source code

Since our custom compiled NodeJS software sits completely in the /opt/node-v8.1.1 directory, removing that software requires no more effort than using the rm command to remove that directory:

BEWARE: sudo and rm -rf are a dangerous cocktail! Always check your command twice before pressing the “enter” key. You won’t have any confirmation message and no undelete if you remove the wrong directory…

Then, if you’ve modified your PATH , you will have to revert those changes, which is not complicated at all.

And if you’ve created links from /usr/local/bin you will have to remove them all:

Wait? Where was the Dependency Hell?

As a final comment, if you read about compiling your own custom software, you might have heard about the dependency hell. This is a nickname for that annoying situation where before being able to successfully compile a software, you must first compile a pre-requisite library, which in its turn requires another library that might in its turn be incompatible with some other software you’ve already installed.

Part of the job of the package maintainers of your distribution is to actually resolve that dependency hell and to ensure the various software of your system are using compatible libraries and are installed in the right order.

For this article, I chose, on purpose, to install NodeJS as it virtually doesn’t have dependencies. I said “virtually” because, in fact, it has dependencies. But the source code of those dependencies are present in the source repository of the project (in the node/deps subdirectory), so you don’t have to download and install them manually before hand.

But if you’re interested in understanding more about that problem and learn how to deal with it, let me know that using the comment section below: that would be a great topic for a more advanced article!

Like what you read? Please share it with others.

Источник