Often the necessary packages can only be found in source form; this article describes a method for installing a package from source code.

Unboxing

Programs are usually distributed in packaged archives, these are files with the extensions

.tar.gz (sometimes .tgz) .tar.bz2

You need to understand the difference between an archiver and a packer.

The program is used to archive directories and files tar; the result of its work is a file with the extension .tar. Roughly speaking, this is a copy of the file system - directories and files with their attributes and access rights, placed in one file.

This file will be slightly larger in size than the total size of the files that were archived. Therefore (or maybe for another reason) they use packers - programs that allow you to reduce the file size without losing data.

Program tar can unpack, so no need to call gunzip, or you can simply tell the program tar that the file must first be unpacked. For example, the command

tar -xvf< some_app_name>.tar.gz

will immediately unpack and unzip. Difference between files and extensions

.tar.gz

.tar.bz2

only that different packers were used, the program tar determines the compression method automatically and additional options not required in this case.

After unpacking, you need to go to the resulting directory; all the commands described below are executed in the directory with the source code of the package.

CD< имя_пакета>*

Building the package

To build programs in GNU/Linux, you use (mostly) the program make, which runs instructions from Makefile, but since there are many GNU/Linux distributions, and they are all different, in order to build the program, for each distribution you need to separately specify the paths where the libraries and header files are located. Programmers cannot study each distribution and create separately for each Makefile. Therefore, they came up with configurators that “study” the system and, in accordance with the knowledge gained, create Makefile. But they didn’t stop at the configurator and came up with configurators of configurators...that’s where they stopped

To build we need compilers: they are specified in the package dependencies build-essential, so it's enough to install it with all the dependencies. Still needed autoconf And automake.

So, to build something from source, you first need to build a configurator; how to build the configurator is described in the configure.in file. To build the configurator you need to run

./ bootstrap ./ autogen.sh

If there are no such scripts in the archive, you can run the following commands in sequence:

aclocal autoheader automake --gnu --add-missing --copy --foreign autoconf -f -Wall

All of these commands use the file configure.in. After executing these commands, a file will be created configure. After this, you need to run the configurator to check for the presence of all dependencies, as well as install additional build options (if possible) and view the installation result (optional - may not be present)

./ configure

The configurator will build a Makefile based on the knowledge gained and the file makefile.am. You can pass to the configurator the options provided in the program sources, which allow you to enable/disable certain program features; usually you can find out about them with the command

./ configure --help

There is also a set of standard options, like

Prefix=

Which specifies which directory to use for installation. Usually for Ubuntu

--prefix =/ usr --prefix =/ usr/ local

WITHOUT slash at the end! Now you can start the process of building the program itself with the command

make

Regular user privileges are sufficient to build. The end of the build can be considered the moment when the commands in the console stop being executed “randomly” and there is no word error. Now everything is compiled and ready for installation.

Installation

Efforts spent on Correct installation in the future, they will more than pay for themselves in the event of uninstalling or updating the installed software.

Correct installation(Option No. 1)

Installation using the utility checkinstall. To install:

sudo apt-get install checkinstall

Minus this method: checkinstall does not understand all sources, since the program author can write special installation scripts and checkinstall won't understand them.

To create and install a deb package you need to run

sudo checkinstall

Correct installation (Option No. 2)

Quickly create a deb package manually.

The main difference from the previous method is that in this case you create the package manually and track all the changes you make. This method will also suit you if the sources do not support building the package with checkinstall.

We install in a temporary directory, where we get the entire set of installed files:

fakeroot make install DESTDIR=`pwd`/tempinstall

Let’s create a DEBIAN directory in the “package root” and add a list of all files that should go into /etc into DEBIAN/conffiles:

cd tempinstall mkdir DEBIAN find etc | sed "s/^/\//" > DEBIAN/ conffiles

Then we create a DEBIAN/control file with the following content:

Package: package_name Version: 1.2.3 Architecture: amd64/i386/armel/all Maintainer: You can enter your name, you can rubbish, but if you leave it empty, then dpkg will swear Depends: Here you can enter a list of packages separated by commas. Priority: optional Description: You also need to enter something so that there are no warnings

If necessary, you can also create preinst, postinst, prerm and postrm scripts there.

We create a deb package, for which we execute:

dpkg -b tempinstall

The output is tempinstall.deb, which we install

sudo dpkg -i tempinstall.deb

Installation (option No. 3)

Incorrect installation

The disadvantage of this method is that if you install directly via make install, then you most likely will not be able to remove or update the package normally. Moreover, installation new version over the old one will most likely overwrite your changes in the configs. make install does exactly what it is told to do - it installs files in the right places, ignoring the fact that something is already there. After this process, it is absolutely impossible to obtain any information about what was placed where and in a digestible form. Sometimes, of course, the Makefile supports the uninstall action, but this is not so common, and it is not a fact that it works correctly. In addition, you will need to store the unpacked source tree and build rules for uninstallation.

To install you need to do

sudo make install

To remove a package installed using this method, you must execute it in the root directory of the program's sources (where you ran make install).

sudo make uninstall

Errors

Often at the configuration stage, the configurator reports that a particular library is missing. The library name it reports doesn't always match the package name in Ubuntu. From my own experience, I can advise you to search Synaptic for the required package, excluding the lib prefix. If you find several packages that differ with the prefix -dev in the name, then you need to install the -dev package (usually it also entails a non-dev package). You can also search using http://packages.ubuntu.com/ by entering the library name into the search for package contents, similarly, if you find dev and non-dev, you need both. Well, or just search on Google.

Necessary software

Packages with mm at the end of the description are packages for C++ programs. List for bmpx, but suitable for almost any GTK2/Gnome program. So if you can’t assemble it, then look at this list and compare it with what you have installed.

	Compile:	Runtime:
X	libx11-dev	libx11-6
GlibMM	libglibmm-2.4-dev	libglibmm-2.4-1c2a
GTK+	libgtk2.0-dev,gtk-doc-tools	libgtk2.0-0
GTKMM	libgtkmm-2.4-dev	libgtkmm-2.4-1c2a
Glade	libglade2-dev	libglade2-0
GladeMM	libglademm-2.4-dev	libglademm-2.4-1c2a
XML	libxml2-dev	libxml2
XML++	libxml++2.6-dev	libxml++2.6c2a
DBus	libdbus-1-dev,libdbus-glib-1-dev	libdbus-1-2,libdbus-glib-1-2
Alsa	libasound2-dev	libasound2
HAL	libhal-dev,libhal-storage-dev	libhal1,libhal-storage1
Gamin	libgamin-dev	libgamin0
Neon	libneon25-dev	libneon25
TagLib	libtagc0-dev	libtagc0
Startup-Notify	libstartup-notification0-dev	libstartup-notification0
Boost	libboost-dev,libboost-filesystem-dev	libboost-filesystem1.33.1
MusicBrainz	libmusicbrainz4-dev	libmusicbrainz4c2a
GStreamer	libgstreamer0.10-dev,libgstreamer-plugins-base0.10-dev	libgstreamer0.10-0,libgstreamer-plugins-base0.10-0

There was a desire to get acquainted with development for Android. I downloaded Android Studio, unpacked it and deleted it. I decided to look for other installation options. While searching, I came across Ubuntu Make (aka Ubuntu Developer Tools Center in the past), and in this short note I want to tell you about it.

Ubuntu Developer Tools Center flashed in the news along with Ubuntu 14.10 (Utopic Unicorn), but, it seems to me, it did not attract widespread attention. Not much later, the project was renamed Ubuntu Make, as it is called to this day, having grown to version 0.4. The development is carried out by Didier Roche, Software Engineer, Canonical. Also noteworthy is the fact that Ubuntu Make is written in Python 3.4.

The main goal of the project is to quickly and easily install common developer needs in Ubuntu. And although it’s still a long way from “general needs” (the list of packages available for installation is still small), with “quick and simple” everything is fine.

On this moment Using Ubuntu Make you can install:

• Android Studio
• Eclipse
• IntelliJ Idea Community Edition
• PyCharm Community Edition
• go-lang Google compiler
• Stencyl game developer IDE

Installation

In ubuntu 15.04, ubuntu-make is available out of the box, users of versions 14.04 and 14.10 are asked to install from ppa:

Sudo add-apt-repository ppa:ubuntu-desktop/ubuntu-make sudo apt-get update sudo apt-get install ubuntu-make

Usage

Installation with ubuntu-make is incredibly simple. For Android installations Studio just run in the terminal:

Umake android
A little wait and here is the result:

Icon in dash and openjdk (if Java was not in the system) included. After launch, the “studio” pulled up the sdk and updated to version 1.0.2. “Hello world” was launched on the phone and the functionality test was completed.

Golang is installed similarly:

For PyCharm, Eclipse, Idea, one more argument will be added:

Umake ide pycharm

To remove a package, just add the "-r" argument to the same line:

Umake ide pycharm -r

Opinion

Someone will say: “There’s a lot to do. Download the archive, unpack it, check the icon in dash and check it in Java. Do you need ubuntu make? I agree, there might not be a lot to do, but I found the package useful for myself. He saved me time and got rid of the routine. I hope it will be useful to you too.

Material from Bryansk Linux Users Group and www.rm.pp.ru

Each distribution has its own specifics for assembling the kernel, and this article is focused specifically on how to do this in Debian Etch. It also reveals the question of how to apply a particular patch to the kernel when support for certain functionality or new equipment in your system is needed. The article is intended primarily for more trained users and there are no guarantees that this method will work as it should and all described actions and responsibility fall on you.

1. Note
2. Applying patches
3. Kernel configuration
4. Compiling the kernel
5. Installing a new kernel
6. Problems
7. Links

Note

Two methods of assembling the kernel will be described. The first option will be described for assembling .deb packages that can be installed on your or another system. The second method is the so-called "traditional" way.

Method one. Building the kernel into .deb packages

Installing the necessary packages to compile the kernel

First, let's update the package lists:

# apt-get update

Let's install the packages we need:

# apt-get install kernel-package libncurses5-dev fakeroot wget bzip2 build-essential

Download the kernel sources

Go to the /usr/src directory, go to www.kernel.org and select the desired kernel version. In this case, the version linux-2.6.23.1.tar.bz2 will be considered. Download:

# cd /usr/src # wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.1.tar.bz2

Let's unpack the sources and create a symbolic link:

# tar xjf linux-2.6.23.1.tar.bz2 # rm linux (remove the previous symlink) # ln -s linux-2.6.23.1 linux # cd /usr/src/linux

Applying patches

Don't do this optionally or unnecessarily!

Sometimes drivers or tools are required that are not supported in the existing kernel, for example virtualization technology or other other specifics that are not in the current release. In any case, this can be corrected by applying so-called patches (if any).

So, let's assume you downloaded the required patch (for example, let's call it patch.bz2) to /usr/src. Let's apply the downloaded patch to our sources (You must still be in the /usr/src/linux directory):

# bzip2 -dc /usr/src/patch.bz2 | patch -p1 --dry-run # bzip2 -dc /usr/src/patch.bz2 | patch -p1

The first command is only a test and no changes will be applied to the sources. If no errors were thrown after the first command, you can run the second command to apply the patch. Under no circumstances should you execute the second command if errors were generated after the first!

This way you can apply patches to the kernel sources. For example, there are some features that are only available in the 2.6.23.8 kernel, and the source code did not contain the necessary functionality, but patch-2.6.23.8.bz2 was released. You can apply this patch to 2.6.23 kernel sources, but not 2.6.23.1 or 2.6.23.3, etc. You can read more about this at:

Prefixes (prepatches) - equivalent to alpha releases; patches must be applied to the sources of the complete previous release with a 3-digit version (for example, patch 2.6.12-rc4 can be applied to the sources of version 2.6.11, but not to version 2.6.11.10.)

This means, if we want to build kernel 2.6.23.8, we need to download the sources of version 2.6.23 (http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.gz) applied in the second method "traditonal" way!

Apply patch-2.6.23.8.bz2 to kernel 2.6.23:

# cd /usr/src # wget http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.22.8.bz2 # cd /usr/src/linux # bzip2 -dc /usr/ src/patch-2.6.23.8.bz2 | patch -p1 --dry-run # bzip2 -dc /usr/src/patch-2.6.23.8.bz2 | patch -p1

Kernel configuration

It's a good idea to use an existing configuration file working kernel and for the new one. Therefore, we copy the existing configuration to /usr/src/linux:

# make clean && make mrproper # cp /boot/config-`uname -r` ./.config # make menuconfig

after which the graphical kernel configuration menu will load. Select the “Load an Alternate Configuration File” item in the configurator menu and click “Ok”. Then (if required) make the necessary changes to the kernel configuration by navigating through the menu (kernel configuration details can be found at www.google.com). When you finish and click “Exit”, the question “Do you wish to save your new kernel configuration?” will be asked, answer in the affirmative “Yes”.

Compiling the kernel

Building the kernel is done in just two commands:

# make-kpkg clean # fakeroot make-kpkg --initrd --append-to-version=-cybermind kernel_image kernel_headers

After --append-to-version=, you can write any name you like, but it must start with a minus sign (-) and have no spaces.

The process of compiling and building .deb packages can take quite a long time. Everything will depend on the kernel configuration and the capabilities of your processor.

Solving the problem with creating initrd.img

Recently, a bug has appeared in Debian in which, after installing packages with kernels assembled using the method described here, the corresponding /boot/initrd.img file is not created. To fix it for an already installed kernel, you will have to create initrd.img manually:

update-initramfs -c -k<полная-версия-ядра>

To solve the problem “for the future,” comment out, as shown, the second of the lines quoted below in the file /etc/kernel/postinst.d/initramfs-tools:

# kernel-package passes an extra arg; hack to not run under kernel-package #[ -z "$2" ] || exit 0

Installing a new kernel

When the kernel build is completed successfully, two .deb packages will be created in the /usr/src directory:

# cd /usr/src # ls -l

linux-image-2.6.23.1-cybermind_2.6.23.1-cybermind-10.00.Custom_i386.deb - the actual kernel itself and linux-headers-2.6.23.1-cybermind_2.6.23.1-cybermind-10.00.Custom_i386.deb - headers kernels needed to build other modules (for example, when building modules nVidia drivers). Install them:

# dpkg -i linux-image-2.6.23.1-cybermind_2.6.23.1-cybermind-10.00.Custom_i386.deb # dpkg -i linux-headers-2.6.23.1-cybermind_2.6.23.1-cybermind-10.00.Custom_i386.deb

(These packages can now be installed on another system and there will be no need to build them again.)

That's it, the installation is complete, the bootloader menu, installation of a new RAM disk and kernel will be done automatically. All that remains is to reboot:

# reboot

Method two. "traditional" way

We carry out all the points described above BEFORE the “Kernel Compilation” point.

# make all # make modules_install # make install

As usual, the build may take a long time, depending on the kernel configuration and processor capabilities.

The main disadvantage of this method is that if you often update kernels, then after a while a large number of them will accumulate and you will want to remove the unused ones. To make this easier, you can assemble the kernel and other files that are installed into the system using the commands “make modules_install” and “make install” into a deb package (or rather, two starting from kernel 2.6.27) similar to the first method, but we’ll use Here are the scripts of the kernel itself:

# make all # make deb-pkg

Two .deb files will appear in the directory one level above the source directory. I assembled the kernel in the /usr/src/linux-2.6.27.10 directory and files appeared in the /usr/src/ directory

# linux-2.6.27.10_2.6.27.10-1_amd64.deb # linux-firmware-image_2.6.27.10-1_all.deb

The kernel is installed with the command

# dpkg -i linux-2.6.27.10_2.6.27.10-1_amd64.deb

Old kernels can be removed, for example, from synaptic"a

Next steps

The kernel has been compiled and installed, but now you need to create a RAM disk (without which the kernel simply will not boot) and you need to update the GRUB boot loader. To do this, do the following:

# depmod 2.6.23.1 # apt-get install yaird

Install the RAM disk:

# mkinitrd.yaird -o /boot/initrd.img-2.6.23.1 2.6.23.1

Let's update the bootloader easily and painlessly:

# update-grub

That's it, the bootloader and the new kernel are ready, all that remains is to reboot:

# reboot

Problems

If, after rebooting, the new kernel you selected does not load, reboot and select your previous kernel and you can try to do the whole process again to build a working kernel. In this case, do not forget to delete the lines of the non-working kernel in /boot/grub/menu.lst.

And also other systems have to be installed additional programs. IN operating systems On Windows everything is very simple, as a rule there is an installer called setup.exe that helps install the software. But in Linux things are a little different. How to install programs on Linux? Now let's look at this question.

Linux has several types of installation packages and each distribution has its own package format. Fedora, Mandriva, Red Hat and Suse distributions use the standard Linux RPM installation developed by Red Hat. The RPM package file is typically named program_name-version.rpm.

Another very popular format is DEB. Used in Debian, Ubuntu, Knoppix and Mepis. Has a name program_name-version.deb.

And we approached the archives. Usually these are .tar , .tar.gz , .tgz extensions. They should be unpacked and then installed/compiled.

You need to perform the program installation procedure as a superuser.

Quick navigation

Installing programs on Debian, Ubuntu

There are many tools for working with DEB packages, but the most commonly used is apt-get, which is included in the standard set of tools. To install the application, enter the command:

apt-get install package_name

For removing:

apt-get remove package_name

APT stores a local database of all packages available for installation and links to where to get them. This database needs to be updated from time to time with the command:

apt-get update

To update outdated packages (programs) on the computer, enter the following commands:

apt-get update ; apt-get upgrade

Installing programs on Fedora, Red Hat

A utility similar to APT is yum. To download and install the package from the configured repository, write the command:

yum install package_name

yum remove package_name

The local yum database is not saved, so there is no need to update. To install updates, use the command:

yum update

Select something specific to update:

yum update package_name

Installing programs in Mandriva

Mandriva has its own set of tools for working with packages, called urpmi. For installation:

urpmi package_name

To delete:

urpme package_name

Update the local database with the list of packages:

urpmi. update -a

To install updates:

urpmi --auto-select

Installing programs from archives (tarballs)

For archives compressed using GZIP (gz, gz2, etc.) we do this:

tar -xvz f filename

For archives compressed using BZIP (bz, bz2, etc.) it’s a little different:

tar -xvjf filename

Tar commands:

• x – extract files from the archive;
• v – detailed display of information on the screen;
• f – Required option. If not specified, Tar will try to use tape instead of file;
• z – process archive compressed using gzip;
• j – process an archive compressed using bzip.

After executing the command, a folder will be created with a name similar to the name of the package. Then you need to open this created folder with the command:

cd folder_name

Next, in the unpacked archive, read the instructions in the README file, if any. In any case, if the program is compiled as an executable file, then the package will contain a .sh file, usually called install.sh

The bottom line is that this command in the form of “make install” or “sudo make install” cannot be used in modern distributions.

But the authors of the programs in the installation manuals write that you need to use this command, you might say. Yes, they write. But this only means that they don’t know what distribution you have, or whether it’s a distribution at all, maybe you joined a sect and smoked reading LFS and now decided to compile their creation for your chthonic system. And make install is a universal, although often incorrect, way to do this.

Lyrical digression

As you know, for normal operation, most software must not only be compiled, but also correctly installed on the system. Programs expect to find the files they need in certain places, and these places on most *nix systems are hard-coded into the code at compile time. In addition to this aspect, the main difference between the installation process in linux/freebsd/whatever and that in Windows and MacOS is that the program does not just put a bunch of files in a separate directory in Program Files or /Applications, but “spreads” itself throughout file system. Libraries go to lib, executable files in bin, configs in etc, various kinds of data in var and so on. If you suddenly need to update it, then all this must first be cleaned somehow, because... when using a new version, leftover files from the old one can lead to completely unpredictable consequences, often not good. The probability of this event is not so high, but do you need it on a production server?

So what?

So, if you did the installation directly via make install, then it’s normal to remove or update the software, you most likely you can't. Moreover, installing a new version over the old one will most likely will overwrite your changes in configs. make install does exactly what it is told to do - it installs files in the right places, ignoring the fact that something is already there. After this process, it is absolutely impossible to obtain any information about what was placed where and in a digestible form. Sometimes, of course, the Makefile supports the uninstall action, but this is not so common, and it is not a fact that it works correctly. In addition, storing the unpacked source tree and build rules for uninstallation is somehow strange.

How to fight?

Since packages in distributions tend to be updated sometimes, to solve this problem they came up with such a thing as package manager. When using it, the installation goes something like this:

1. an archive formed in a certain way is taken
2. information is extracted from it about what it is, what version it is, what it depends on, what it conflicts with, whether it is necessary to run any scripts to install/uninstall/configure, etc.
3. Direct installation steps in progress
4. All data about where and what was delivered is added to the package manager database.

In this case, when updating, you can painlessly remove unnecessary things, and at the same time see if the files marked as configuration have changed in the system and ask what to do if their contents are different in the new version. In addition, the package manager will not allow you to overwrite the files of one package when installing another. In general, it can do a lot of useful things.

If you, out of ignorance/laziness, copied and pasted make install from the instructions, then files appear on the system that the package manager does not know about. With all that it implies, if what was listed earlier is not enough for you.

What to do?

You can, of course, configure the source tree so that everything is installed somewhere in /opt/mycoolapp/, and then, if necessary, delete it manually, but a lot of unpleasant things can come out here, starting with the fact that the program expects that it can load your libraries, and the loader knows nothing about the directory where they are located, ending with the fact that the program author can expect that, for example, if he puts a file, say, in $prefix/share/xsessions/, then the display manager will pick it up. Not to mention the paths for pkgconfig and so on.

So you need to collect the package.

I don’t have time to fuck with this, I’d better do make install again, everything is simple and clear!

Calm down, calm down. He's tied to our legs. Everything is not as scary and complicated as it seems at first glance.

checkinstall

This wonderful utility, when launched instead of make install, will ask several questions, after which it will build and install the package. That’s it, when updating you won’t have any problems with cleaning out old junk.

Building the deb package manually

If you are not inclined to trust such automation (which sometimes still messes up) or you want to make a couple of changes, but are still too lazy to deal with the normal process of building packages, then you can assemble the package manually. I give a way to build it for systems on Debian database, because I am best familiar with them. It is not ideologically correct, but the output is a completely correct package without the use of additional entities. This is done as follows.
First, we assemble the software with the --prefix=/usr and --exec-prefix=/usr parameters pre-specified for configure or autogen.sh.
Next, we install it in a temporary directory. We write:

Fakeroot make install DESTDIR=`pwd`/tempinstall
After which we get the entire set of files in the newly created directory. By the way, we are now in a fakeroot environment, i.e. you can change the owner and access rights of files without any restrictions, but physically you will remain the owner of the system. The software inside the fakeroot session will receive changed information, which will allow files with the correct rights to be archived.
Next, create a DEBIAN directory in the “package root” and add a list of all files that should go into /etc into DEBIAN/conffiles:

Cd tempinstall mkdir DEBIAN find etc | sed "s/^/\//" > DEBIAN/conffiles
Then we create a DEBIAN/control file with the following content:

If necessary, you can also create preinst, postinst, prerm and postrm scripts there.

That's it, we do dpkg -b tempinstall and the output is tempinstall.deb, which you can use dpkg -i to install, update or remove correctly.

The “correct” process of preliminary creation of a source code package is beyond the scope of this note, and therefore will not be described, but for your purposes it is usually not necessary.

Conclusion

As you can see, there is absolutely nothing complicated here, but following these steps will save you from a huge number of problems in the future.