Exploring an RPM package

- [Narrator] Now that we know what we're looking for, and before we begin creating packages, let's take apart some packages that already exist. I'll download the package for nano, our lightweight text editor. And this one is a binary package. And I'll download the source package for nano as well. I'm using CentOS 8, so I have dnf, which you'll also have on Fedora. If you're using an older release of a Distro Linux ecosystem, you'll need to use yum, and use the yum downloader tool from the yum utils package. Using the RPM tool and some of its query options, we can take a look at parts of these packages. I'll start with rpm -qi, and one of the packages. And here I can see package information. I can also take a look at the files contained within the package with rpm -ql and the package name. Those don't really matter right now. The point is, this package contains the files that will be ultimately placed at these paths. If I take a look at the source package, I can see there's only three files, .gz.tar file, which contains the source code, the nano spec file and the nanorc file, the initial startup configuration for the software. There are a few other queries that can be useful when exploring packages too. rpm -q --requires reads the packages metadata to see what the author has said the package requires software wise in order to run or build properly. And we can see what scripts are included in the spec file as well, as instructions for the package manager. With rpm -q --scripts. These are post install and pre uninstalled bash scripts that place or remove documentation for the program. If we want to explore further, we can extract the contents of the packages as files. Remember, RPM packages use cpio archives to contain the actual files within them. We can pull the files out with various commands. First to keep things organized, I'll create directories to put the package files into. All right, make directory nano source and nano bin. One method to pull out the files, is to use the cpio program directly and pipe the output of the rpm2cpio command into it. I'll pipe that into cpio with the options imD and the directory where I want the files to end up. Okay, and that's the source package extracted, so let's go look around. Here's the same files I saw when I used rpm to list the files, which makes sense. But now I can work with them and read them if I want to. Let's take a look at the spec file for this package. Here I can see the information that the package maintainer provided, and here's the build requires entries to make sure the package manager knows that the build process will need these tools to succeed. We can't build this source code without these programs. The spec files of build build, aren't going to be as complex as this, but it's always useful to explore complex examples in order to extend your learning. Scrolling down, I can see the build scripts that the packager has written in order for the make tool to build and install the source code. Here's the list of the files in the package. Again, using macros to ensure the paths are correct on a target machine. And here's the change log. Going all the way back to 2003. I'll quit by pressing Q and go back to the prompt. In order to get at the source code for this package, I can extract the archive here. And there's the source and supporting files, like documentation and make files. And this isn't the programming course, but if you're curious, you can explore the source code that makes up this tool. That's useful if you need to modify how something works or to fork a project for your own purposes. I'll quit out of here and move back to my home directory. The other tool we can use to extract files from packages is part of the RPM built tool set. And it's a little easier to use than the other method, though the results are the same. I'll write rpmdev-extract and the package name, and this command will create a directory in the current working directory with the name of the package and put the files into there. But I already made a directory. So, I'll modify this a bit to tell the tool to put the new directory inside nano bin. And there's the binary package extracted. I see an etc and the usr directory, because when a binary packages installed, the package manager moves files into the directories the packager has indicated. Ordinarily, the directory trees represented here would be based in the root of the file system. But because we've just extracted them, they're based out of whatever directory we want. We can take a look at the contents of these. With tree, etc, not much interesting there, just the initial rc file for nano and tree usr. There's some more interesting stuff. I'll scroll up here to the start of that commands output. Here, I can see that there's an executable that would go into usr bin, and a bunch of files inside usr share doc. A lot of localization files, the man pages for this tool, and some language specific settings for the editor. If we need to, we can work with these files and I can even run nano from here, even though it's not installed on my system. One thing you won't find here though, is a spec file. Binary packages don't contain a spec file. Those are only kept in source packages. So keep that in mind as you explore packages and as you build your own, you'll either want to keep a copy of the rpm build directory for packages you create, or make sure to create a source rpm as an archive for your work. Exploring packages that have already been built is a great way to improve your understanding of packaging. And it's crucial if you're working with existing packages to update them or to branch source packages.