CIQ
HomeCIQ Webinars

Rocky Linux HOWTO Series: Building a Rocky RPM package

October 27, 2022

In this webinar, we will demonstrate how to build a Rocky Linux RPM package. Don’t miss this exciting and informative webinar!

RPM Package Manager (RPM) (originally Red Hat Package Manager, now a recursive acronym) is a free, open-source software package management system. The name RPM refers both to the .rpm file format and the package manager program itself. RPM was intended primarily for Linux distributions; the file format is the baseline package format of the Linux Standard Base.

Webinar Synopsis:

  • How Have RPMs Changed?

  • Where do RPM Packages Come From?

  • What If You Don’t Have the Source File?

  • Demo

  • Chroot and Containers

  • Does Mock Clean the Environment?

  • Are Some Packages Omitted From the Minimal Base System?

  • Are There Things You Don’t Need to Say in Your Spec File?

  • Other Distro’s

  • The Build Process For New Config File and Repositories

  • Rebuilding Rocky Linux Packages

  • Can You Cross Compile?

  • i686 Packages On a x86_64 System

  • 32-bit Packages

  • Did You Do a 32-bit Kernel?

  • Kernels While Running Mock

  • Individuals Messing With Default Packages

  • The Mock Build Process is Smoother

Speakers:

  • Gregory Kurtzer, CEO, CIQ

  • Skip Grube, Senior Linux Engineer, CIQ

  • Jonathon Anderson, HPC System Engineer Sr., CIQ

Note: This transcript was created using speech recognition software. While it has been reviewed by human transcribers, it may contain errors.

Full Webinar Transcript:

Zane Hamilton:

Good morning, good afternoon, and good evening, wherever you are. Welcome to another CNX CIQ webinar. My name is Zane Hamilton. I'm the Vice President of Sales Engineering at CIQ. At CIQ we are focused on powering the next generation of software infrastructure, leveraging the capabilities of cloud, hyperscale and HPC. From research to the enterprise, our customers rely on us for the ultimate Rocky Linux Warewulf, and Apptainer support escalation. We provide deep development capabilities and solutions, all delivered in the collaborative spirit of open source. Today we're going to be talking about RPMs and how to create them. I would like to welcome Skip Grube and Jonathon Anderson. Skip, would you introduce yourself?

Skip Grube:

My name is Skip Grube. I began my career as a Rocky Linux release engineering contributor, something I still do to this day.  I spend a lot of time building packages. When package builds don’t succeed, I check on them. I am also a Linux engineer at CIQ.

How Have RPMs Changed? [01:16]

Zane Hamilton:

Thank you, Skip. Our conversation last night was focused on RPMs.  I realized that I hadn’t worked on one for a long time. I was looking at my old notes and saw comments like “this is painful” or “I don’t ever want to do this again.” How have RPMs changed? 

Skip Grube:

Yes. How

Skip Grube:

I remember when it was difficult. A tool that we still use is rpm-build. The tool has undergone many changes. We are also going to talk about a simple and powerful wrapper around rpm-build called Mock. . Rpm-build was really frustrating because you had to get everything just right such as setting your directories properly, macros, and then it might work. It could work for you, but then it wouldn’t work for someone else. Mock has made it so that we no longer have to worry about that. For example, instead of having Zane build the RPM on his system or Jonathon build an RPM on his system, Mock creates either a searu or container.

The idea is to quickly spin up a minimal Rocky Linux or other Linux system within your current box. You can then run the build inside that minimal system only using things available within the system. Unable to see anything else, the build will produce results and collect logs. It is simple and significantly easier than setting up rpm-build and doing this by yourself. Today we are going to demonstrate how to use the Mock and rpm-build to build a Rocky RPM package. 

Where do RPM Packages Come From? [03:49]

The first thing I want to talk about is where do RPM packages come from? Many people don’t understand that when you do DNF install or YUM command (the precursor to DNF), under your Linux box , RPMs are compiled from source RPMs. Source RPMs come from code. There are three components to a source RPM. There is usually a zip file or tarball with source code in it. This also means that we are going to talk about the Bash shell. 

Can I share my screen and present? This will be easier to demo than to tell. We're going to go to one of my most visited sites, the Raw Rocky Linux download pages. I know that you can browse these and they are also automatically added in your DNF Files. You can also go to /etc/yum.repos.d,, but I will show you that in a minute. We are going to click in here. Rocky Linux distributes source packages with their binaries. 

We are going to look at the bash source package. There are three components to a source RPM. There is a spec file that looks like this. It is a recipe for doing a rpm-build. Though we aren’t going to dive deep into this right now, it has the name, version it depends on, and making it bigger. It contains complex documentation that tells us how to build whatever we are trying to build. It shows us commands, whether it is a Makefile in a GCC or Python. It provides all the things that the package requires to complete the build. Bash has a lot of content. It has the second component of source RPM known as patches. Our upstream provider is Red Hat so most of these patches are issued by them. 

There are things that are added on to the main bash source code. Oftentimes they are backports to fix little bugs, security issues, or even a behavior change to be more conducive to enterprise Linux.  The final component is the zip file or the tarball. That is in here. If you go into here and look at source0 you can see where the upstream source file originated. If you go to the gnu ftp server at this location you will see that these match exactly. Our base version is 5.1. That is everything we need to compile our bash. 

What If You Don’t Have the Source File? [07:27]

Jonathon Anderson:

If you don't have the source file, will it pull it down from that URL automatically?

Skip Grube:

It will not. It has to be bundled. The source RPM is expected to be able to compile without any internet access. We want to make sure that we have everything bundled together within our source RPM.First thing we need is a Rocky Lenox system. Doesn't necessarily have to be a Linux system, but as a member of the Rocky Lenox team, you can imagine I have a bunch of VMs, I've got a bunch of all kinds of things, uh, going on, ready to go. Once we have the source RPM this has made this much easier to understand. It is only source code and a spec file recipe on how to build it. I would like to show everyone how to build it. 

Demo [8:16]

The first thing you need is a Rocky Linux system or another functional system. As a member of the Rocky Linux team I already have many VMs and other things ready to use. I got everything running. We're going to load up a terminal and ssh into it because that will be easier than using the VM screen.  The first thing we're going to do is use four commands here to set up our Mock.  The first one (that many people are familiar with) is sudo dnf install epel-release. Epel, for those that are not familiar, is an excellent collection. It is a third party repository that stands for extra packages for Enterprise Linux and it has a bunch of stuff including this Mock program that we're about to install. This repository is maintained by the Fedora project and has a bunch of extra packages and stuff that you might find interesting for Rocky Linux or Red Hat Enterprise Linux. Now that we have our epel powers enabled, we can do dnf install mock. It is a very simple package. There are going to be a few Python dependencies because it was written in Python, but as you can see it is quite small for what it does. This package is less than 200 kilobytes. Now we are going to go ahead and install some support stuff.

I am not in the mock group so I am going to change that.  It is possible but I prefer to not do it on the system. You can run it as a normal user. Users in the mock group are allowed to run mock build. We are going to add me (Skip) to the mock group. Then we need to log in again to update the mock group membership. I will check to see if it worked and now I am a mock user with build powers.

The next thing we need to do is scroll to our vaunted Bash source RPM that we saw earlier. We're going to grab it and download it. Let's go.. Since we have a source file I am going to create a temporary folder to prevent cluttering up anything with logs. We have our source rpm and out  our mock built program. I enjoy seeing how fast compilation happens and how fast systems work. I always do build time to check speed and for benchmarking.

 -v for verbose. Verbose is important. Then do - - resultdir /home/skip/tmp That is the current directory.  Then do /home/skip/bash.  This is the source RPM. I'm going to press enter and watch it work. While this is working we need to take some time to explain what's happening. The Mock program is creating and installing a minimalistic Rocky Linux system in my virtual machine inside chroot. It is a container environment.

There are some packages here that are the bare minimum required. This way you can run DNF to install more packages effectively. This will look familiar to anyone who has installed packages before. Once that step is done it is going to read the bash spec file that we downloaded. It will say “what are the requirements that I need to build this package?” Then it will install only those packages. It will proceed to read it and call rpm-build just like normal, but inside the minimal system and perform a build. This way we are doing in a place where it has the minimum required to build bash without anything extra. 

Chroot and Containers [13:41]

Zane Hamilton:

I have some questions about this minimal environment. Earlier you mentioned chroot or a container. How does this work? What is it doing underneath? Is it really a container platform? Is there something else I have to do?

Skip Grube:

There are two options in Mock. The default option is systemd-nspawn container. You can read all kinds of wonderful technical details about that. It's a systemd feature that allows you to create containers without Docker Podman.  Systemd will talk directly to the kernel to see groups and create a container for you with storage, networking and everything. And it's it's very nice because this program, you don't want to, you could use Docker to run rpm-build, but we don't, we don't want that overhead, right? We don't need a whole Docker install to do this. And we're interested in just spinning up the bare minimum environment and then we're going to discard it at the end of this. Like this is all once we have our build and our, our resulting RPMs, then we don't we don't care anymore. It is a very nice feature because, while you could use Docker Podeman to run rpm-build, we don’t want the overhead. We are only interested in spinning up the bare minimum environment and then discard it at the end. Once we have our build and resulting RPMs we don’t care anymore. 

We will discard the environment and next time we call for a package we will load a new environment. This way we keep things clean. Systemd-nspawn is new to enterprise Linux. You can run it with a simple chroot without containers. You can use the old chroot developed in the 1980s. It will do the same thing, but with differences in technical details. Containers and chroot can see different aspects of the kernel. You might run into some issues if you are running an advanced build with chroot. In bash it is a simple package so we are going to keep using the default. 

Does Mock Clean the Environment? [15:44]

Zane Hamilton:

Whenever this environment is created we want things to be clean and simple. Does Mock clean the environment for you? Is there anything to consider after it is finished?

Skip Grube:

By default it cleans it up. However, I would encourage everyone to get into Mock building because there are millions of options. And you can say especially for troubleshooting, hey, when you're done, do not clean this up, right? Go leave, leave the directories lying around so that if something went wrong, we can actually go into the ch route and check out like what was going on, like what files were produced, right? For example, for troubleshooting we can tell the system to “not clean certain things. Leave the directories lying around so that if something goes wrong we can go into the chroot and investigate what files were produced.” If there was an error, a file that was missed, or something, we can explore that. I know there are a lot of scary texts but  this is what happens when you compile bash. I can show you the text because it is straightforward and not a mystery. This is an excellent tool. I am going to become root for this because I need to be root to explore. 

When you install Mock, there's a mock here and  a couple of folders. We're going to go into the mock config (your configuration for mock sets). We'll go into that in a minute and you can see here's root. if you look at my system here this looks like a root directory. This is where bash is being built as we speak. I'll bet if we go into the build here there will be all kinds of stuff going on inside this wonderful little directory. If we wanted to, we could explore the gcc (what it's pulling as it happens). I'm not going to get into that right now, but  this is the chroot or the container in this case. There is an option to Mock called - - no clean or something like that. This option will not remove stuff when we’re done. It will keep everything around so that someone can investigate and see what went wrong. 

Are Some Packages Omitted From the Minimal Base System? [18:18]

Jonathon Anderson:

We have talked a little bit about the benefit of listing all your build requirements in the spec file. Is it normal for some packages to be omitted from that list in the minimal base system? Does that package make assumptions about the base system and only define requirements that would go on? 

Skip Grube:

This is an excellent question. You are referring to the initial set of packages. That was the first dnf command that was run inside of our mock, called a Buildroot. It's there to  bootstrap a minimal Rocky system. Your rpm-build requirements are only as sound as how minimal your Buildroot is. For example, if you throw Java into your Buildroot (this is a terrible idea) and your RPM requires Java without specifying it, that will cause issues for someone who doesn’t have Java. It’s not a requirement. 

Your question is difficult to answer.  The defaults for Mock are very good. They are as minimal as possible while still having a functional system.  It is up to the user to take things away. Let’s look at our log and I will show you what I am talking about. Look at that Bash RPM. I enjoy testing my RPMs so lets take the new RPM and overwrite/remove the current Bash. Then we will install the one we just produced. We shouldn’t have any issues because it is the same version. 

Even though they are the identical we installed and are running the new Bash. We just built our own shell interpreter.  Anyway, returning to your question, let's check out when the system begins. root.log is the Mock set up process for creating the container. This is the stuff that it needs to install before compilation is done. If we scroll down here we can see the list of packages. There aren’t very many. You won’t be able to take very many things out of there and have a functional system. If you are interested, you could always add things, but be careful. For every RPM package you should expect these to be present. You can always specify them. For example you can always specify “I need grep or gzip.” Almost every system you encounter is going to have this stuff and its dependencies. I hope I properly answered your question without beating around the bush too much. 

Are There Things You Don’t Need to Say in Your Spec File? [22:04]

Jonathon Anderson:

Maybe a point of reference is I don't think I've ever seen a package say that it depends on or build depends on glibc.Is it acceptable to have things you don’t have to say in your spec file?

Skip Grube:

It depends on the system you're building for. For example, Rocky Linux packages come from a tightly controlled system based entirely on Red Hat Enterprise Linux.If you run Red Hat Enterprise Linux you are also running glibc without it being specified.  It's not normally specified. I can imagine a situation via container or via something else where you have an RPM based distribution that has musl libc that would need to be specified within your package. It entirely depends on your RPMs intended audience or build distro. 

We're very fortunate in Rocky Linux to have Red Hat Enterprise Linux. We have a very high quality upstream. There still might be problems when you build 3000 plus packages to mail to distro. Many things might come up such as bugging. Most run of the mill packages like this one are pretty solid. It looks like we built it. 

Other Distro’s [23:48]

I'm going to go off on a little tangent here because we were talking about other distros. It's important to note if you're not familiar with Mock or this process. Mock is a Fedora tool. It's used a lot across the spectrum. This is not just a Rocky Linux thing. So if you go into /epc/mock/ configuration directory there are a lot of distros. There are some cool things we can do with this tool. When we create chroot and begin our build process it doesn’t have Rocky 9.0. We build Rocky 9 Bash, but you have the option to use other systems. We could specify CentOS 7, Fedora 1, or openSUSE and use a Bash design for any of those builds. The only limitation is you have to use an RPM based distro. 

There are so many in there. There are a ton of derivatives and distributions. The one I used is the default Rocky 9.  It’s default on this system because the packages of Mock say “if you’re using Rocky 9, they will assume you want to build Rocky 9 packages.  As you can see this is just a Python config file here. It's a bit of Python code. This is a Python dictionary and it's really cool how the settings are set. Let's check out this template file. This one is really interesting. I will show you high in the curtain with Mock. 

Is very interesting. If you've ever edited YUM or DNF config files, you will be familiar with this. It's fascinating because you have to remember when you're building an RPM package the location where you grab it’s dependencies matters. It is very important.  In Mock you can manipulate this to be whatever you want it to be. Right now this is the default, but you can change the DNF priorities to say,“I want my own repository that I hold on to. I want you to get your GCC or your dependencies from there first.” You can manipulate the versions that you're building against. For example, the following might be an issue. Maybe your Ruby package will not build because openSSL breaks it. So instead you might have to build it against a slightly older openSSL at build time so it complies. There are all kinds of things you can do such as injecting your own dependencies to change Buildroot. You can customize your system to build your RPM in limitless ways.  

The Build Process For New Config File and Repositories [27:17]

Jonathon Anderson:

What is the process like for creating a new config file and the repositories it draws from?

Skip Grube:

You have to start somewhere.  There are several ways to do it. We are very fortunate because Rocky is a downstream distribution. We have excellent upstreams in Red Hat Enterprise Linux and CentOS 9 stream. To get started we bootstrapped Rocky Linux 9 off of Red Hat 9 Beta. It was released in December or January of this year. I can show because I am heavily involved. I have a web server that the project allows me to use. Let's look at aarch64/. In Rocky Linux we have to do this for around 5 different architectures. 

We compile for the ARM processors like Raspberry Pi. We compile for 32-bit.  We compile for Intel 64-bit. These are your default laptop, desktop, server processors. We compile for s390X., This is the IBM mainframe System Z processors. We also compile for PowerPC  which is another IBM derived processor line. All of these are generally fine. They are very consistent. Every once in a while we’ll have an issue where it compiles for everything but s390X and we have to investigate. There is a lot of problem solving. The repository here is huge. There are 8,000 or more packages in the repository. This is here because I had to do a complete rebuild of what’s in Red Hat Enterprise, Linux 9, and CentOS 9 Stream in order for the build team to get going. 

This is how we start. We download source code, put together source RPMs and begin this Mock process over and over again. There are tools and automation to help us. It's not like I'm just sitting here by candle light saying, “oh gosh, I'm going to build this  3000 more times. Now we have tools to make the machine do the work. You will see that this requires a lot of effort and time. These are free to browse. You can see how Rocky Linux 9 was bootstrapped. If you go through this I hope you have a lot of memory in your browser because these are some big listings.

Rebuilding Rocky Linux Packages [30:41]

Jonathon Anderson:

I know you mentioned bootstrap. Once you have a set of packages from somewhere and build Rocky Linux packages against them, do you have to rebuild all the Rocky Linux packages?

Skip Grube:

Yes. You’ll notice right here that this says directory stage 1. There is so much more. I think this segways us nicely into a new topic, Peridot. This is a public site: paradot.build.resf.org. Because this is a public site anyone can browse this. However, not everyone will be able to import and build stuff. Let’s check out Rocky Linux 9 and go into builds. I am going to check out this one called “nodejs.” This is everyone's favorite JavaScript server. To be honest I don’t understand it very well. 

Skip Grube:

In this there are a bunch of tasks that happen. These are the interesting ones. It says build for x86_64 or build for i686. These are different architectures that we are building for.

Skip Grube:

Due to some technical issues I am going to select a different one. This one is called bind, otherwise known as everyone’s favorite DNS server. If we scroll to the top you may notice that this text looks familiar. When our build system (Peridot, API, Koji which is a Fedora CentOS system and Gooey, among others) they are very organized and elaborate ways for calling Mock and rpm-build.  And so like this, this text out here is almost identical to what we were just doing in our, if I can Back Into my bill directory here, you'll see a little clearer here. 

For this X here we installed a bunch of initial packages that the RPM requires. Then it executes rpm-build like we just did. THis is an excellent way of doing local testing/builds. If you set your Mock config correctly, you can make it completely compatible with the real Rocky Linux, CentOS, or the Red Hat Enterprise Linux projects. 

Can You Cross Compile? [34:02]

Audience Member:

With Mock, can you cross compile? For example, making an RPM for ARM on a x86 machine?

You will not be able to cross compile. Um, RPM in general does not natively support cross compiling. It is possible, but the logic to do it has to be built into the spec file.. I’ve seen some from QEMU that are like this. Most packages are not going to bother having this feature because they assume if you want to perform a cross compilation you have access to the system that also has a compiler. For bootstrapping initial systems this would go beyond the scope of this talk. This would delve into cross compiling things manually to get RPM and basic packages going. 

Let's say that a completely new processor architecture comes out and we have to build software for it. There is going to be some more fundamental work before you can even begin to think about RPMs. The goal when we begin porting a system for this is to get enough stuff so we can get this to Buildroot. This is the initial set of packages that we have inside of Mock. Once we have that, we can get rolling, we can say,  “we'll build very slowly.” We can get  some basic packages going like the C compiler. I don’t want to get into this process, but it is very complicated. The short answer is no.

i686 Packages On a x86_64 System [36:17]

Jonathon Anderson:

What about I686 packages on an x86_64 system?

Skip Grube:

That will work fine. With ARM64 you can compile as long as the processor supports it. We know x86_64 and Intel processors support 32 bit mode. Some ARM64 processors are also backwards compatible with ARM32 in the same way. Let’s take a look at an i686 build. 

Jonathon Anderson:

Presumably you'll still need a 32-bit bootstrap to or environment to build against. 

Skip Grube:

That makes a big difference. Because as long as you have some RPM macros (which Mock does for you set to be set to the proper processor architecture) then you have a proper Buildroot and build environment that supports it. We can look up here.  You will notice that when we're installing here, this entire system is i686. There is no 64-bit stuff going on here. This is because 32-bit packages do not need 64-bit packages. In fact, they actively don't want them in order to build. I think you’re next question will be about why we build 32-bit packages when Rocky Linux and Red Hat Enterprise Linux does not release a 32-bit version. 

32-bit Packages [38:19]

Jonathon Anderson:

Where is my 32-bit ISO?

Skip Grube:

The reason that we build 32-bit packages is because if you look at your Rocky Linux repositories and, and upstream Red Hat repositories, there are certain packages like OpenSSL and several others that include 32-bit variants. If you want the 32-bit version for whatever reason you can install that.They exist for compatibility's sake for a lot of commercial software. They might distribute a 32-bit version and they need 32-bit openness to sell. In the beginning the Rocky team decided we are going to compile these 20 and 32-packages. We will compile OpenSSL. “This will be just fine.” Then they would look at other ones that require 10 packages for 32-bit. “Okay we’ll do those too.” After around 150 we thought, “we’re compiling everything.” CentOS came to this conclusion before us, but in order to build these 32-bit packages, we have to build 32-bit for everything. I don’t want to get into this too much right now, but if you connect Peridot DNF repo or Webuild 8 in Koji 32-bit packages are supported. Firefox will actually refuse to build with 32-bit.They are intentionally excluded, but most of them are there. We initially thought it would be super easy to throw 20-30 cubit packages in. Then after a few days of building we realized that our dependencies had dependencies. We might as well build everything. So we did. 

Did You Do a 32-bit Kernel? [40:37]

Jonathon Anderson:

Do you also do a 32 bit kernel?

Skip Grube:

No. That is one of the packages that excludes 32-bit. This is also a big reason we don’t have 32-bit ISO. Hypothetically speaking, if someone really wants a 32-bit system, you could take 32-bit builds we have completed for all user space and make it compatible with a 32-bit kern package. Put them together and produce an ISO or an image. It would work, it would just also be a lot of work. I’m not sure if it is worth it. 32-bit hardware is becoming increasingly irrelevant. For that reason it isn’t something that we’re interested in doing. 

Kernels While Running Mock [41:23]

Jonathon Anderson:

The last big thing we need to talk about is the kernel itself. The kernel crosses the boundary, but is not part of the isolation. Even though running Mock is a container, you’re doing the build with the kernel of the host system, regardless of what you’re targeting. Has this ever come up? Is it an issue?

Skip Grube:

Yes.Usually in ways you wouldn't think about. A good example is while we were building Rocky Linux 9  there was a Ruby package that was required. We were so backed up at the time. I think even now we're building Rocky Linux 9 on Rocky Linux 8 systems. They're running containers, but they have a Rocky Linux 8 kernel. It’s a little older, but still well supported and there is the Ruby package. It might not actually be the Ruby package, but it is related to Ruby. For its compilation it runs testing and requires a kernel for support It’s not only tmpfs, the temporary file system feature, we have in our Rocky 8 Kernel. There is also tmpfs feature called O_kemp. 

I can't remember exactly the feature it provides, but it's a new thing in the Rocky Linux 9 Kernel. Anyway, the Ruby tests would not pass. The tests are done at the end of compilation for an RPM. To ensure the binaries are working properly. We ran into a problem and in order to make sure everything was okay we had to upgrade the kernel on some of our build machines.  This way it would support the new tmpfs feature. 

Jonathon Anderson:

Have you ever encountered a situation where it works in the other direction? For example, you have a newer kernel, but something you're trying to build requires an older one?

Skip Grube:

My memory is very fuzzy on this. I want to say yes, but I don't have a specific example.. I have run into a ton of awful problems such as that, where we’ve had to investigate and fix. 

Jonathon Anderson:

, My question was “has this problem occurred?” The answer is almost certainly yes, right? 

Skip Grube:

When you break things in so many different ways, it will make your head spin. Many people say ““it's so easy.” You're just calling these RPM bills over and over again. If all of them were completed on the first try my job would be very simple.  I'm happy to give it up to anybody who wants to do it. The problem is when things don't go right, and we have to spend hours to days trying to  figure out, for example, why won't this work and why did it work before? There's a lot that goes into that. Oftentimes it has to do with the versions of things that you're bringing in and building against. Sometimes a new version comes out and it will break at build time in an unexpected way.

Jonathon Anderson:

“How did this ever work before?” This is the worst question in systems engineering.

Skip Grube:

It comes up more than you would think RPMbuilding. Building in Mock here is great if you want to build two-five packages. When we're talking about industrial capacity and we need to build 5,000 packages this comes in handy. We can do mass builds and not have to do it one at a time. 

Individuals Messing With Default Packages [45:24]

Zane Hamilton:

Have you run into users out there that are taking default packages, messing with them, then posting them into their own repository? Do they have something that’s required for their company environment?

Skip Grube:

This brings me to another great point: we already know that we can get our source RPMs from our download site.  They are available via DNF command. If you check out your  yum.repos.d. Rocky Linux and other distros come with source repositories and all they do is point to these source RPMs. However, these source RPMs have to come from somewhere.We want to go to another great site git.rockylinux.org/staging/rpms/bash

And you'll see here we've got some branches. Branches are funny when it comes to distros here. This is Rocky 8 and Rocky 9. We never merge branches. These are just the different versions that we keep track of. You can see when things were imported. The latest version of Bash for Rocky 9 was imported five months ago and built. There hasn't been any updates from Red Hat since then. You'll notice here, sources and specs. Let me pull up the old source RPM that we got from here. If you browse this source here, I'm going to put it on top here so that we can see him side by side. You'll notice specs bash dot spec is right up here.

If you go into sources here, you'll see all these patch files. They should exactly match. That's where you want to know where these source RPMs come from.  This is open to everybody. You can clone it, you can muck with it, you can do whatever you want with it, and you can build your own. You don't want our bash build. Make your own fixed bash. Put in your own patches. This is where our sources come from. git.centos.org/rpms/bash is where Red Hat publishes their official source code. . They have branches. If you want the CentOS 4 (c4) bash, We're not really interested in that. We'll check out. There is no CentOS 9 , but they still call it c9.  This is the Red Hat source code and this is exactly where we got it. It gets pulled down and tagged into our git here. You can see the flow of where these things come from. If you're interested in modifying it is simple to get started. I’m not a C programmer so I won’t say it is easy.y.

The Mock Build Process is Smoother [47:35]

That was all I had planned for today. If you are building RPMs, please consider using Mock to use rpm-build. It's hard and it's outdated.I used to hate doing this. My company would sometimes ask me to build a customized RPM for different programs. I dreaded having to figure it out. Mock has made this process so much smoother. Mock has done a lot for package building. Especially RPM package building. Containers have done so much for developers. We have a standardized base that we can build on. We can make sure that when I build a package in my Mock, it's going to be the same as a package built in anyone's Mock. As long as our configurations are the same, we should get the same result. 

So please consider doing this it if you're still using raw rpm-build to build packages. Nobody should be using raw rpm-build because it is really rough. You will never have to configure RPM Macros again.  Configuring RPM macros are the same as configuring Mock. It's inside that Mock configuration file. You can set macros like you can do everything else. It's much easier than having to mess around on your file system trying to locate RPM macros. 

Zane Hamilton:

That's great. I don't think we have any more questions. I really appreciate you coming on Skip and for putting this together. 

Join us next week and like can subscribe. See you next week. Thanks.