Explore the concept of package management. Understand how repositories work.
- [Instructor] On a Linux system, we can add, remove, update, and otherwise modify the software that's installed, in case we need to add functionality, or remove outdated software, or apply a security update if a vulnerability is found, and so on. The software that we use is generally more complex than a few lines of text, so it's delivered in two primary ways: as source code files, or as pre-compiled binary files. While decades ago, we might've sat down and diligently copied source code out of the back of a magazine to create software that we wanted to use, in today's world, we rely heavily on packaged software instead.
I don't mean packaged up in plastic, in a box, on the shelf. I mean that this software comes in a neat little bundle, usually one file that wraps up everything needed to make that software work on our system. Or, if not everything, then at least it comes with references to where the system can find what it needs. These packages can contain source code, pre-built binaries, scripts, and metadata to tell a package management system how to deal with what's in the package. These scripts and metadata answer questions like, does the software need to be moved to a particular folder? Does it need to be compiled? Does it have any dependencies or requirements that need to be fulfilled by having other software available before it will run correctly? What needs to be done before or after compiling or copying the files to wherever they need to be? All of this information is bundled up in a package.
Some software works all on its own, but most of the time, packages that we install will need some other components to make them work. These are called dependencies, because a package depends on these other packages. Commonly, packages will depend on a particular programming language, or tool chain, or shared library. While it might seem easier to just combine everything that a given package needs into one big bundle, it's a lot more efficient to just refer to packages that are needed instead. This makes things more modular, and allows for individual smaller packages to be updated more easily.
The name for the process of figuring out what dependencies a package has, and whether they're available or need to be installed, is dependency resolution. It's a process that can be done manually, but package management software handles it for us, which is nice. There can still be problems, however, if it happens that a combination of packages ends up with a circular reference, or if a required dependency conflicts with something that another package requires. The software can usually figure out what's needed, but sometimes, manual intervention is required. The software we use to work with packages is called package management software.
Some tools can work with packages as individual files that have been downloaded, and other software can go out and search repositories, or repos, for software, automatically download the required packages, and then work with those files as needed. Repositories are huge lists of packages that are available for download and installation. Linux distros come with some addresses for official repositories already included, and you can add others if need be. The official repositories for a given distribution, such as CentOS 7, or Ubuntu 16.04, are maintained by teams of humans who test, package, and release software into the repositories.
Depending on the intention of the distro, or the nature of the software, you may find that the available version of software packages varies between distros, sometimes significantly. Some distros are more cutting edge, and others more conservative, when it comes to what software is made available. So, for example, on CentOS, you'll find older packages, and on Fedora, you'll typically find newer ones. The package management software also keeps track of what's installed, where things are, and what version everything is, in case it needs to be removed, updated, or audited.
With these terms in mind, let's go through a general example of using a package manager to install some software. Let's say I want to install PHP on my system. Using my package management software, I'll request to install it. The software will check and see if it's already installed, and if not, it'll go look through the list of software on the known repositories, and search for packages matching the name I've specified. It'll read the package information to see if there are any dependencies that it needs to download. Then, it'll download all of the required packages. After that, the software will either install the package, or figure out what needs to be installed first.
During the installation, some scripts may run, some code may be compiled, and files are copied into locations on your computer, specified by the package creator. Then, some cleanup scripts may run. And you're finished. The software is installed, and ready to use. Of course, there's more detail to it than that, and in the rest of this course, we'll explore a bit further.
- Managing packages with RPM and YUM
- Downloading a package file
- Finding package information
- Exploring package dependencies
- Installing a package and checking what has been installed
- Installing groups of packages
- Adding software from third parties to your installation
- Removing and upgrading a package
- Managing packages with dpkg and APT package managers
- Exploring aptitude