Linux Package Managers (Linux+ Objective 1.6.1)

Hello, everybody. I'm Shawn Powers, and

today we are talking about packages.

Oh my God. Look at my package.

No. We're talking about Linux packages--

specifically RPM and DEB-based package

management as part of the Linux+

exam objectives. Whether or not you want

to take the exam, that's what we're basing this video on. So we're going to

look at package management using

multiple tools: DNF, YUM, APT, Zypper, and

we're going to look at the two different

types of packages that are specified here--RPM, and then it doesn't spell it

out, but DEB packages for .deb files. And that's what we're going to look at.

Even though there are other options out there

for package management, these are the

main ones that we're going to look at.

They're the most common. They're used in

Red Hat variants and Debian variants

like Ubuntu, etc. And we're going to talk

just briefly about these. This is an odd sort of thing they added on to the

objectives, but kernel updates generally

require a reboot--not always, but almost always.

They’ll require a reboot, and they'll have to rebuild a bunch of modules.

So this isn't necessarily done every time

you update your system. You can update

packages either--depending on your distribution--you can update all the

packages, or you can update only the packages that need security updates.

There are several different ways you can go about updating packages and

kernel updates. And the most important

thing is to make sure that you have the most recent versions if there are

security fixes. But we're going to look at a bunch of different tools that you

can use to manage packages on your system, because by default, just

managing individual packages is not the way to go. Like I said, we're

going to look at DEB files like .deb, which comes from Debian, and

then .rpm, which stands for Red Hat Package Manager.

Back in the old days, there didn’t use to be this big

database-driven way to install and manage things on your system.

You used to have to install the .rpm or .deb

files, and it was really a pain in the butt because an individual RPM file or

DEB file does not necessarily contain all the dependencies.

Although they do know what dependencies they require,

if you try to install them manually, you

end up with a nightmare. Let me show you

what I mean. First, we'll start with Rocky Linux,

which is the same as Red Hat. So it uses RPM. Like I said, this is Rocky

Linux, which is just like Red Hat Enterprise Linux version 9.

I think this is Rocky version 9. Anyway, in here, I have an RPM file.

Now, this is not normally how you would get a file

installed on your Linux system, but it used to be this way. And occasionally,

you'll have to install an RPM. But let's

say we had this RPM file and we wanted to install it using just the RPM tools--

not the package management system.

Well, we would do: sudo rpm -i for install

and then the file that we want to install.

And now, if there are no dependencies or all the dependencies are

already installed on your system, hey--no

problem. However--well, I’ve got to put in my password--

you'll see here it's not going to install because we also have to have

libteam and libteam.so.5, which is probably part of the libteam file.

Yeah. That’s actually what it's saying.

It needs it from the libteam file. So what

we would have to do is go online and

try to find the proper version of libteam.rpm with the exact version

that we're looking for on the repos.

We would install that. And then, if that has

its own dependencies, we end up in something that used to be called "RPM

Hell." It was kind of a play on the term "DLL Hell," which is what Windows

users would talk about—like, "This DLL (Dynamic Link Library) in Windows

interferes with that DLL, and so I can't

have them both installed, and I can't get

my package to work," etc., etc. So this used

to be a very frustrating way to install

packages. And, of course, it's not limited

just to RPM-based things. The same thing is true on a Debian or Ubuntu

system that uses DEBs. So here, I'm on an

Ubuntu system which uses .deb files,

and you'll see I've already downloaded one.

This is curl, like the curl we talked about in a previous video. curl is used to

fetch a URL or a file online.

The curl program, though--to install it--we

could use the dpkg program, which manually

handles .deb files. So we could do: sudo dpkg -i for install and then this

file, curl, blah, blah, blah, blah, blah, and

we'll press enter. And if there were no

dependencies that were unmet, it would have installed and been available on our system to use.

However, just like with that RPM file,

this says: "Well, no. This depends on libcurl4." So, in the old days, we’d

have to go and find libcurl with the exact version it's looking

for, install that .deb file. Of course, that .deb file might have some other

dependency--like libcurl might depend on

glibc or something--and we’d have to find

that one and go all the way back until all the dependencies were met.

But thankfully, there is a better way.

In fact, there are quite a few better ways.

Because in the world of RPMs--like using Red Hat

or Rocky Linux, or even SUSE Linux, which

also uses the RPM system--there are package management systems that kind of

wrap around RPMs or DEBs, in the case of a Debian-based system.

And they kind of keep a database of all the

available packages on a repository on the Internet. When you say, "I want to

install something," it says, "Okay, what other dependencies are there?"

Then it finds all of those dependencies,

downloads and installs them, so you

don't have to track down each individual

one. It has made managing Linux so much better than it used to be.

But there are a lot of ways to skin the same cat--which is a horrible, horrible metaphor.

I don't like that. There are a lot of ways to manage packages in Linux.

I’ll show you the various ways mentioned in the

objectives, but note that there are others. Like,

if you're using Arch Linux, there's going to be Pacman.

We're not covering that. We're just going to cover the ones mentioned

in the objectives--and they are the most common.

So, for example, we're back here.

We're on Rocky Linux, which, like I said,

is just like Red Hat Linux. And instead

of using the RPM tool, we can say: "Oh, well,

there are two different tools that come with Red Hat variants," which is

interesting. One is yum, which stands for Yellowdog Updater Modified.

There's another whole story there. And the other

one is dnf, which was written by Red Hat,

and it stands for Dandified Yum, which I think is a little bit silly. dnf is newer.

It's the one that you should be using on

a Red Hat-based system because it has a

few more features--like the ability to roll back if you want to make a change.

I'll show you what I mean. But first of all, to install--let’s say--this

teamd thing that I had downloaded, we could say:

sudo yum install teamd

And this is the difference. See, we

couldn't install it before because there

were dependencies. The dependencies were

libteam. And like I said, libteam might

have its own dependencies--and sure enough, it does. If you look,

libteam apparently depends on libnl3-cli.

But the nice thing about using a package management system like YUM is

that it gets all of those dependencies and installs all of them.

So, in order to use YUM to install this teamd

package that I just randomly picked, I would just say "yes," and it would download

all of the packages required, install the dependencies, and then install that

package. Now, I'm going to say "no," not

because this doesn't work--this would

work perfectly fine--but I want to show

you how you would do the exact same thing using DNF.

In fact, the command-line flags are almost identical

when you're using DNF or YUM. So let's say:

sudo dnf install teamd.

And by looking at it, it even looks exactly the

same, right? It just has some more features.

So it's YUM, but "dandified"--thus the name, DNF.

And this is going to do the exact same thing. It's going to download the

dependencies. We'll actually do it this

time, but it does the same thing whether you're using YUM or DNF.

It's saying that there is a GPG key. Do I want to import that?

I'm going to say yes. I want to import that, and boom.

There--it installed it, and now it's running, and it keeps like a

database of everything that is installed on the system. So the next time we

install something, if one of its

dependencies is this teamd or libteam or whatever it was, it'll say, "Oh,

that's already installed." I don't need to

download that. So like I said, YUM and DNF

are almost exactly the same when you're

using them on the command line. It's very

possible that YUM will go away in the future. Right now, it's still installed.

It's still a perfectly cromulent way to,

you know, manage the packages on your system, and you can mix or match.

You could use YUM, and then you could use DNF.

They have the same database of information that they pull from.

So you can use either or right now, but it would

not surprise me if YUM goes away in some future version of Red Hat stuff.

It's just been replaced by DNF, so there's no

reason not to use DNF. And DNF will do--like I said--it will roll back.

It'll allow you to take back, like, if you

install something on your side and you want

to undo that, DNF allows you to do that,

whereas Yum does not. And that really is

one of the big differences between the

two--DNF has more features, that being

a main one. But whether you're using DNF

or Yum, you can do things like update,

which will update all the packages on your system. If you say "update" and

a package name, it will only update that

one package. I'll show you really quick

how to do the rollback, because since we use DNF, we could rollback.

So we're back here on the system where we just

installed team d. Actually, I don't even know what team d is, but we just

installed that. And now if we do DNF--now,

we don't have to be root to do this one--but we could say dnf history,

and it's going to show us the stuff that it did. Now, since it shows a full

history, you're going to see that before the video, I actually removed team d

so that all this would work. But this shows

a history of all the things that have been done with DNF on the system.

And since we see that this was done--the

install of team d was ID number three--

we can say (now this does require sudo

because it's going to make some system-wide changes), sudo

dnf history undo 3, that last thing. If we do that,

it's going to remove the packages and

the dependencies that we just installed.

Basically, it's going to just roll back exactly what we just did.

So I'm going to say yes, and now we don't have team d

installed anymore. So that's one of the

advantages of DNF over Yum. When it comes

to upgrading packages on your system, whether you're using Yum or DNF,

there are two very similar-sounding and kind

of confusing terms. You can either do

Yum or DNF update, and if you do that--if

you specify a package--it's just going to

update that one package. But if you do it

without any other, you know, things at the

end--just update and press enter--it's

going to update all of the packages on

your system, which is normally what you

want to do. Normally, you want to update

all the packages to get them up to date,

and you can see there's a whole bunch of

them. It actually shows you different kinds, like it's going to install a new

kernel because there's a new kernel, and then it will activate that, so I have

to restart. It's going to upgrade all these packages, and it's going to install

these dependencies down here because the new updated

packages require updated dependencies as well. So you can do

update, and that's pretty safe. The other

thing--the other option that you have--I'm going to say no here.

The other option you have--and again, whether using DNF or

Yum, so we'll use DNF this time just

because--you can say upgrade instead of

update. And the difference here is that it's going to allow the system to get

rid of obsolete packages. And these are

packages that are obsolete, no longer,

like, current. However, it's possible that

some of those packages are things you're still using.

So it's a little more dangerous to do upgrade. A lot of times,

if you have upgraded from, like, Red Hat 8 to Red Hat 9 on your system,

you can do upgrade and it will get rid

of obsolete packages and replace them with

updated ones. But just know that it could break stuff if you're actually using

those older packages. So upgrade is

generally not used as much as update on

a Red Hat system, but it will say upgrade

and it's going to do the exact same thing. In this case, it's the same packages.

There aren't any obsolete ones that it's, you know, worrying about

getting rid of because, again, we're not

changing anything drastic on our system.

And so it's going to do the exact same thing, but just know that upgrade has

the potential to break stuff easier than

update does. And I hate that it's, like, such similar words, but the thing is,

upgrade--think of it as, like, I upgraded

to a new version of the Linux system as

opposed to just updating my current packages. Maybe that'll help.

Anyway, we say "y". It's going to go download all of

the stuff. It's going to install it.

Again, in this case, it's a kernel package that

it's updating and going to recompile all the modules that it needs to, and

it will tell us that we need to reboot in order to, you know, complete and

activate it. And so if that's the kind of thing that it's a production system,

you may have to time when you can upgrade

it, if it's going to require a reboot.

Now, you probably remember that I said SUSE

Linux also uses RPM, and that's true.

The underlying packages are RPM on a SUSE

Linux box. However, it does not use Yum or DNF to manage the packages.

It uses something called Zypper. And so I'll show you that.

Again, the underlying stuff is still RPM files, and that's how it, you

know, maintains its packages. But the actual system to keep track of

dependencies and what's installed, and where all the repositories online

are and stuff, that uses the Zypper program, which is completely different

from Red Hat or Rocky Linux. So I'm here

on openSUSE, and this is, again, an RPM-based system, but it uses Zypper.

And Zypper has slightly different commands

in order to do things, rather than just

update and upgrade. There are update or just up. It allows you to use shortcuts.

There is dist-upgrade, which is very rarely used, and that's the same sort

of thing where it can remove packages for you even if you don't want it to.

So we don't normally do dist-upgrade,

but Zypper, or openSUSE, has another

option that Red Hat doesn't, and that's

called patch. And patch basically just installs the very important things, like

security updates and stuff, that, you know,

if there's a security release that has to be installed even on a production

system, you can do patch and it will install those without updating all of

the other packages that may have updates,

but they're not, like, super important. They're not security-related updates.

So patch is something that you can use more

often on a production system, knowing that it's just going to update the

things that are a security risk on your system.

It's kind of cool, actually. And it works similarly: sudo zypper is

the program instead of DNF or Yum.

It's Zypper, and then you can do things. And I

didn't show you this with Yum and DNF, but you can search for a package too.

So we'll do it here. It works the same on

the others. I mean, you can play with it and look at the man page.

But we can say search for Firefox, I guess. Oh, and this

is something. It says "sudo password for root," but it's my local password

that it wants. That's just some weird openSUSE thing.

And it looked in its repositories, and these are the things that it found.

So we could install, for example, Mozilla Firefox. We can install using

Zypper, and it's going--let's do it. sudo zypper install or you can just do in.

They're real big on shortcuts, but, I mean,

it's confusing enough having multiple ways to install packages on multiple

distros. So I'm just going to type the whole thing: install MozillaFirefox.

Now it did the exact same thing. It found any dependencies that it might

need, and it did find a dependency. It said it's going to install the following

two packages--this package and this package--in order to get the Mozilla

Firefox. And it looks like it's going to

upgrade it. It looks like it's already installed, which is fine. So, do I want to

do this? "Y" is the default, but I'm going

to say yes. It's going to download all of those things. It's going to install it.

And I shouldn't have said yes--I'll just fast-forward.

I won't make you wait. But, oh, really quickly--look.

See, it's downloading RPM files. So it is using an RPM system underneath.

So I'm glad I hit enter so I could show you that.

So okay. That's installed. We could do

the same thing with, you know, update or dist-upgrade.

But the one thing that's kind of unique here: sudo zypper patch.

What this will do is--there's nothing to do.

There are no security issues currently on the

system that a patch would do.

So we can--even if, you know, there are upgrades

available or updates available for our

packages--we don't have to necessarily

install them on a production system because there are no security ones

currently available. Hopefully, that makes sense.

That's, again, a big deal. But we could do sudo zypper

update, and this will update all the packages that are available to update.

And you can see, if we hit "yes" here, it's going to get 232 packages to

upgrade, three of them new. One of them is going to change its architecture,

interestingly enough. But notice here it says openSUSE Tumbleweed

requires zypper dup. dup--again, they're all about

shortcuts--is short for dist-upgrade. And that's because Tumbleweed--

I'm getting in the weeds here with SUSE--but in the weeds.

I didn't even mean that. It's a rolling distribution, and

so that means that basically, upgrade will be more common

because it doesn't, like, have releases. It just is a rolling release. So to fully

upgrade Tumbleweed, we will do dist-upgrade or just dup, its shortcut.

So I'm going to say "no" just so I can show you that, and then we'll be done.

sudo zypper--I could do dup, but again, I don't like that.

dist-upgrade, and this is going to go through and now install--again,

it's installing the same packages. It's just

telling you, like, hey, when you have Tumbleweed, the rolling distribution,

you should use dist-upgrade. So, you know, do it that way, you will.

Usually, we don't use that in a production server

environment anyway, but nonetheless, that's the difference between the two.

We can press enter and it's going to upgrade all of the things. But it does

tell us that a system reboot is going to be required because it's installing a

new kernel, which is awesome information for it to tell us in advance.

And that leaves us with the system that I actually prefer and use the most:

a Debian-based system or .deb files using APT. And APT is the package

management system for .deb files. APT is used in Ubuntu and Debian.

There are some others, like apt-get, which is kind of a

package management system that uses the

APT database. And just like you can use

Yum and DNF at the same time, you can use

APT and apt-get, and it just writes to

the same database. So you can use either one.

APT alone--APT--is the most recent one, and it's the one mentioned in the objective.

So that's what I'm going to show you. That's what I use. And there are

a couple of nuances with deb-based systems versus RPM-based systems.

And the biggest difference--and this really is a big

difference--is that with Yum and DNF and

Zypper, when you search for a package or install a package, before it does

anything, those systems will go and refresh everything on the web.

Like, they will get an update of all of the available packages and versions.

But with an APT-based system, that's an extra step. You actually have

to refresh the "what is available" database, and to do that: sudo apt update.

So in this case, update means "I want to

update my cached information of packages

that are available and what versions are

on my repositories on the internet."

So it means something drastically different.

But it's important to do this first because if you don't update, then you

have old information. You don't know what

packages are available. So sudo apt update--oh, come on. There. Finally.

And it will refresh its cache of what stuff is available.

This goes pretty quick. As you can see, it's

already done, and now we can use APT to upgrade or dist-upgrade.

And this is similar in that, like, the different

degrees of upgrade--because upgrade is

going to do all the packages that have updates, but it's not going to allow it

to remove packages and, like, do big changes. This is the same sort of thing.

Generally, dist-upgrade in an APT system

is a little more dangerous--and "dangerous" isn't really a good word, but it's

more apt (and that's too punny for me to say).

It's possible that if you do dist-upgrade, it might break packages on your

system. But if you're going from one version to another, dist-upgrade

will bring all of your packages up to the current distribution numbers,

version by removing old stuff and installing the new versions of them if

they exist, that sort of thing.

So generally, you just do upgrade, but dist-upgrade is available

if you have, like, a drastic change that you've done.

And so we can simply do sudo apt upgrade.

Oh--when we used the dpkg to install curl, it screwed up the database.

Do you remember earlier when I tried to do it manually?

It actually screwed it up. And so what we can do--we could say

sudo apt -f install, and it will fix what I broke.

In fact, in this case, it's going to install curl properly by

getting its dependencies. So I'm going to say "yes," and that's a really

nice feature--that it will clean up my mess because I tried to do it manually.

Even though I would never do that in real life, I was showing you kind of the

old way that we had to do it. Anyway, so

it's fixed that, and now I can actually run upgrade, and it'll say, okay, there

are 75 upgrades, five new installs, three are not upgraded, 30 are standard

security updates. And so, this is how you can keep your system up to date.

It says that these have been held back. If we

were to do dist-upgrade, these would also be upgraded. But, again, it has

the potential to break your system, maybe.

Yeah. It's kind of a frustrating thing. Generally, you can avoid dist-upgrade

and just do upgrade and you'll be fine.

So that's pretty much what we would do here. I just press enter--it's

going to go and upgrade all the stuff.

So depending on your system, you have lots

of options for package management.

The big thing to remember is: on a Debian-based system, so using APT,

you have to do apt update and then apt upgrade.

In fact, you have to do apt update before you do, like, an apt install.

So, like, if we were to do apt install firefox, we'd have to do apt update first.

Otherwise, it's going to try to pull an old version that doesn't exist anymore.

So you always need to do apt update before you make any

changes to your system. It's funny that

Yum and DNF and Zypper all do that step

automatically, and APT just doesn't--but that's how it is.

With great power comes great responsibility, and this is one of

those examples. Anyway, I hope that was helpful.

I encourage you to play with the different tools to see what they can do,

and the different options, and how they work differently. Install a couple of

system distributions in a virtualized environment--so if you break it,

you know, so what? And just have fun. But as always, learn everything,

do what you love, and most importantly, be kind.

I'll see you in the next video.