hpr-knowledge-base/hpr_transcripts/hpr0872.txt

Episode: 872
Title: HPR0872: Packaging YUM
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0872/hpr0872.mp3
Transcribed: 2025-10-08 03:54:30

---

Hello welcome to Hacker Public Radio, this is Clat 2 and today I'm going to go over
some of my very favorite young commands.
Yum is of course the yellow dog update manager or modified or something like that.
He was this package managing front end to RPM that a distribution called yellow dog came
up with.
Yellow dog, you may or may not recognize the name now, used to be apparently sort of a big
name on PlayStation and PowerPC Linux distributions.
And anyway they were either based or inspired strongly by Fedora and so they came up with
this little nice user friendly front end to the default package manager at the time
called RPM.
RPM I've used a little bit, but typically if you're using Fedora or Red Hat or CentOS or
Scientific Linux or whatever, you're using Yum.
So Yum is a very cool little command and I think that it's worth going over because at
least in my mind, a package manager is only ever any good if you actually know what
you're doing.
This can be said of most applications if you think about it, I think I've possibly touched
on this subject on my other show, but a new world order.
It's worth saying here as well and that is that you can't really critique an application
until you get to know it, which is totally backwards if you think about it.
I mean, if you don't like an application, the last thing in the world you want to do
is get to know it.
And yet at the same time, that's the only way you can really critique it.
That's the only way you can say anything about it because otherwise you're just firing
blanks.
You're just shooting in the dark.
You're just coming up with complaints and the minute they're out of your mouth someone
says, well, actually, it's really easy to do that.
You just do yum dash capital C and it does that.
So what are you talking about?
And you're like, I don't know what I'm talking about because you don't.
You don't know what you're talking about.
So this is how I am with app to get.
Every time I complain about app to get in IRC, I know and I usually try to state after
I have made my obligatory complaint that I'm only complaining because I'm not reading
the manual.
I didn't sit down and read up on how to do some fancy little task for which no one should
ever be doing.
Especially if I'm ripping out some kind of package from the default devian install to put
in my own, some modified version of that from a different repository, you don't do that
sort of thing without reading up on how to do it.
And then you go and do it without reading up on doing it and it messes up and then you
complain about it.
Well, that's why.
So yum is the package manager that I kind of know, I mean, aside from like Slack builds.
The yum is the one that I use quite frequently on Fedora and now actually even on Red Hat.
So that's the one that I started looking into to really get to know and learn.
So I thought I'd go over some of my favorite commands within yum and then hopefully maybe
possibly someone will come out with an episode about their favorite apt-get commands or
their favorite, what is it, Pac-Man or AUR or whatever arch Linux uses all that stuff.
It would be really good, I think, in educational for us all to listen and share and learn.
So anyway, yum.
You have to run it as root or mostly you have to run it as root because obviously you're
messing around with your system applications and stuff like that.
So it does expect you to have root power at least.
I just run it as root.
So if you do an SU and into your root password and you can get into yum, one of my favorite
features of yum.
This has been one of my favorite features for a very long time and I don't actually know
a really, honestly, any package manager that has this feature other than yum.
But again, it's probably simply because of my ignorance on the subjects.
But the feature that I'm speaking of is the group suite or the group functions of yum and
I'll tell you all about them.
So first of all, yum is a command with a bunch of sub-commands.
It's sort of a software suite if you will.
I think of it like I think of Git, for instance, or public in where you say, Git, check out
such and such a file or git push or git remove or git add or git commit.
It's Git is the sort of like, OK, I'm going to give you a git command and then you say
the git command.
And then sometimes you say some kind of argument thereafter.
So yum is a lot like that.
You'll be saying you'll be typing in yum and then you will give some kind of command after
that and then maybe you'll give some kind of argument after those.
So the first one that I usually start with after a fresh install of Fedora is always
the group stuff.
So I do yum group list, all one group list is one word.
So it's yum space group list and you'll probably want to pipe that through less because
what that does is give you a full listing of these groups that I don't really know who,
maybe the Fedora community, maybe the Red Hat people, I'm not really sure who comes up
with these groups but there is a set of groups and each of those groups contains a number
of software titles that if you do a yum group install, such and such a group, then you
get all of these software applications installed for free by which I mean without really having
to think about it.
This is completely unlike me to like this feature, right, I'm a slack or a user.
I state that I want full control over my system.
Well on Fedora, I don't really care, the reason that one might sit down in front of Fedora
is because it's a very sort of desktop-y fast paced kind of distribution, so you're updating
a lot, you're reinstalling or upgrading to the latest version of it a lot, you're doing
all these cutting edge things.
So if I'm doing a fresh install of Fedora, the last thing I want to do is go through
my system and carefully and delicately design every single application and every font and
everything that goes into it, I don't care.
So this is a really, really handy tool actually and 9x out of 10, I'm perfectly happy, actually
so far 10x out of 10, I'm perfectly happy with what I get in these group installs.
So sample groups would be for instance, there's the KDE software compilation, KDE
space software space compilation, that's actually not one I usually install because I usually
install the KDE version of Fedora anyway, but another one would be text-based internet
for instance, window space managers, x software development, system tools, sound and video,
various slash productivity, network space servers, mySQL database, obvious sort of really
common groups of really commonly installed software packages, probably if you're going
to, for instance, install mySQL database, you can probably already think of other things
that you're going to install along with it, right?
You're not just going to do my SQL server, you're going to do mySQL client, mySQL admin
or maybe that comes with server, I don't really remember, PHP my admin, come on, you
know you're going to do it, all kinds of little things like that.
So rather than doing a young install, mySQL dash database, mySQL dash client, all these other
things that you know you're going to do every single time, just do a young space group
install and then you'll have to escape it because there's a space in the name.
MySQL space database, close quote, and hit return, and that sure enough installs the group
mySQL database.
Well, what if you don't know what's in that group you want to know before you install it?
That's understandable.
So that would be young space group info and then again quote mySQL space database in quote.
And that looks at the metadata about that group of packages and lists exactly what's
in the group of mySQL database.
And sure enough, it's got all the usual or a bunch of the usual things that you're going
to get along with mySQL, mySQL dash Python, some lib dbd things that are probably for web
servers, mySQL server, Perl, dbd, mySQL, mod off mySQL, so some Apache modules, PHP, my
SQL, Q3, mySQL, Q3, mySQL, lots of different things.
And actually PHP, my admin is not installed on that.
That's probably comes along with web server group, I don't know.
But the point is that you've got a bunch of packages all grouped together in something
that's very logical and for 90% of the users out there, it's probably either exactly
what you wanted or it's really, really close.
So if we do a young group info on sound, space and video, I can bet you anything that it's
not exactly how I would install the sound and video stuff that I would want on a system,
but it's probably really, really close and sure enough, it is really, really close.
It's got all the different codecs, it's got VLC, it's got a couple of sound making applications,
like Rose Garden, it's got a bunch of myth stuff that I would never in real life
install, but you take the good with the bad or the stuff that you're not going to use
with the stuff that you are going to use, and you can whittle it down and really get
in there and be very, very, you know, actually tell it which one to install and which one
not to install, but I don't ever really do that, to be honest.
So that's the group suite, group list, group info and group install that will get you set
up with a really nice system with essentially one command, because what I usually do is
I do it just a group, a young group install, and then I list all the different groups that
I want to install, you might have to do like a group list first just to remember what
groups there are, so that's two commands, but then the next one is going to be young group
install, and then you just list all the different groups that you want to install with quotation
marks around them if they have funky characters or spaces in their name, and then you're done.
The only other young group command there is of course is group remove, which removes
the group.
I actually have never used that command because I'm always so happy with the groups that
I install.
So another really important command that I learned pretty quickly was young what provides,
and again that's all one word.
I think that either since I learned that one, or maybe it was already like this and I just
didn't learn it like this, there is a young provides.
This is really handy when you're looking for a package or an application and you don't
know what package it gets contained in.
I used to have this problem a lot with things like GCC or G++ on different distributions.
I get it on Fedora now because of the group install, I do a group install of the software
development stuff.
It grabs all of the GCC, all the different compilers and different development files and
stuff like that, the header files, whatever.
So I don't really have to deal with that now.
And even if I did, I think I would understand well enough that G++ was basically a version
of GCC that's going to come along with the GCC package in Fedora.
But I didn't know that at one time, so young provides would have helped me with that.
More recently I was looking for JRE, which is a Java runtime environment.
I really don't know that much about Java to be honest.
So I knew that it was, I mean, I knew JRE was Java.
I didn't know what it was going to be called.
I didn't know what to really look for.
And I typed in like a yum search JRE.
And it came up with like JRE factory and JRE factory Java doc.
No idea what a JRE factory is.
I don't know if that's what I want.
I'm pretty sure it's not, it turns out yum provides JRE does a full listing of anything
with the JRE flag set on it or the keyword of JRE associated with it.
And it turns out that you can get the Java 1.6 OpenJDK, which happens to be an OpenJDK runtime
environment, aka JRE.
Or you can get the 1.5 version or you can get the something else G's CJ, I don't know.
The point is that you find the four packages in the repository or the many repositories that
I've got on this box right there, you know, where at least what to look into, see what
you need.
And of course that leads me right into yum info.
So if we saw that we've got an interesting looking package, we're not really too sure
if it's what we're looking for or not.
We can copy the name from our yum provides and then do a yum space info space name of
that package.
And it tells me exactly what that package does.
And it tells me in the description that it is the OpenJDK runtime environment, okay granted
that's actually not much more than what the name of the package tells me.
But obviously in other packages, it's a lot more informative and more interesting and
more complex.
So there you go.
Yum provides yum info.
Yum list is also really great.
Yum list is basically everything that you've got on your system already installed.
So if you can't remember what exactly you've installed lately or where you got it from,
like what repository you got it from, yum list will give you all of that information and
I do mean all of that information.
There might be another place to look for this information on the system.
I actually don't know.
I think of this in my mind as doing an L.S. on slash, slash, slash log, slash packages
in, in Slackware tells you exactly what packages have been installed, what files are in those
packet, you know, got installed along with those packages, stuff like that.
This is very, very similar.
If you're going to do a yum list, you're either going to want to pipe it through.
Grab if you're looking for something very specific where you're going to want to pipe it or
rather redirect it into a text file so that you can search it later on because it will
tell you everything.
But the nice thing that it does tell you is it tells you what the package is called, what
version number you have installed and what repository it comes from.
So already just kind of scanning through the results of my yum list.
I see Fedora.
Fedora.
I see updates.
I see RPM Fusion free, RPM Fusion free, updates, RPM Fusion non-free.
That was a XV, I'm not really sure what that is, something graphical, but I don't really
remember doing that, but whatever.
But this is really great.
Obviously, if you're looking to kind of get a feel for what you've done to your system,
what you've got on it, what you don't have on it, whatever yum list is, is what gives
you that kind of information.
Okay.
So speaking of installing stuff from other repositories, one thing that you do sometimes
is you install an RPM that you got from some other website outside of your repository.
This used to be called a local install.
They've deprecated the turn local install, now it's just install, so it's yum install,
some package.
The difference would be that you've got an RPM that you found online, you downloaded
the RPM itself, and you want to install it on the command line for whatever reason.
Now in real life, if you go out onto the inner webs and you find an RPM from a reliable
source, I typically only am doing this if I'm going to a website that, you know, the
actual application's website, I don't go to one of these sites that sort of collects
all the RPMs or just offers random RPM from random people.
But for instance, animation package that I really like called Synfig Studio.
When it comes out with a new version, I want that new version right now, so I very often
go over to their site, Synfig Studio.org or Synfig.org, and I go to the downloads and
I find the latest version that they've got and they package it up for RPM as an RPM.
So I grab the RPM, actually there's three RPMs, if I'm remembering correctly, I might
be misremembering and thinking of the source code packages, which I frequently use on the
Slackware builds.
But for Fedora, there's either a package or three packages that you have to install, grab
those or that, and then you can do a yum local install.
I use the term local install still out of habit, although I've read in the man page of
yum that is actually deprecated, it's just yum, well not deprecated, it's still supported
just for legacy purposes, but you're not supposed to use it.
So yum install and then dot slash the name of that package sitting on your hard drive.
Simple enough, like I say, in real life, if you did that, if you downloaded it, when you
start downloading it, something's going to catch you and say, hey, this is an RPM, would
you like to open this in your package manager and install it there?
I never do that because I think way back in the early days of doing this stuff, I had
a couple of experiences where I just wouldn't install it correctly or whatever.
And I just kind of fell out of the habit of using a graphical package manager.
So I typically am just doing it on the command line.
So if you do a yum install dot slash sinfig-0.6 or whatever, dash no arch, let's say,
rpm, then it's going to warn you that it doesn't want to install that package because
it doesn't have any signature or any GPG key record for that package, meaning that that
package has no recognizable digital signature.
The reason that Fedora and other distributions use digital signatures are so that there's
a level of familiarity between you and your source of applications.
So if you are grabbing packages from a server and you have previously imported a certificate
or a signature key file into your system, then your package manager is going to look
at your certificate, the GPG key that you imported into its database.
And it's going to check that against the package that you are now trying to install.
And if there's a mismatch, then obviously something's wrong.
Why would there be a mismatch?
Well, because that's not the package you think it is or someone hacked into the repository,
which of course has happened.
So having that GPG key from that server on your computer in your RPM database is really,
really important.
But if you're installing something that has no GPG key signature like Synfig, then you
can't very well, for instance, import their GPG key into your database and then install
the package because they just don't offer that or if they do, maybe you don't know about
it yet.
I don't think they offer it though.
But the workaround would be no GPG check and then hit return and that would work.
So the full command would be yum install, dash, dash, no GPG check, space.slash, Synfig,
risk, RPM, return.
And that would successfully install that application and it is, of course, skipping the GPG key check.
So it's not going to complain about how it's completely insecure and untrusted and you
should never do that.
And you really shouldn't ever do that.
I mean, in theory, because you're bypassing a security check that is built in to make
sure that you're getting the package that you believe you're getting.
The RPM distributor at least has some kind of MD5 sum or something so that you can
verify that yes, okay, this package is what I think it is.
But you obviously do want to make sure that it's coming from a trusted source because
you really don't have any way of knowing what that source is unless you've gone to that
repository before, you've imported their GPG key and then you're able to work with their
packages in a secure way.
The GPG key importing process is fairly invisible to you usually.
I mean, certainly the ones, you know, the default repositories that kind of are associated
with Fedora from a fresh install, well, those GPG keys are there.
They are imported because they're preset in your system.
That's the repository that is added to your system by default.
But if you go to a place, for instance, like RPMfusion.org, RPMfusion.org is the official
unofficial repository for all of those packages that Fedora cannot or does not want to carry
themselves.
But they're from pretty well established sources.
Everyone seems to be pretty okay with RPMfusion.
Everyone kind of knows the people behind it.
It's some of the most reliable and trusted old places that used to have the extra stuff
for Fedora and they've all come together into one big place called RPMfusion.
And if you go there, you can get packages for Fedora and even Rell or Sintos or whatever,
although I have to say that they don't really have that many packages for Rell.
But Fedora, they do have quite a few for that and so when you're importing it or when
you're adding their repository to your list, rather, and there's a really easy way to
do it.
There's a configuration page and you simply go in, grab a prebuilt command that they give
you, paste it into your terminal and it runs and installs, grabs the RPM that is basically
the setting for that repository and adds it to your system.
And of course, along with that, it's importing their own GPG key into your database so that
your system is familiar with RPMfusion packages and will not throw errors unless there's
some reason to believe that the signatures aren't matching and that there's some problem,
which you should probably not ignore.
But if it's a local install, you're not going to have the GPG key imported into your database
so you need to skip over it with dash dash, no GPG check.
The other thing that you need to do because now you've done a local install of some package.
So you have basically overridden the normal method of tracking a package.
Normally, Yum wants to own your packages.
It wants to be able to look at that package, it wants to look at the version number and
it wants to compare it with whatever is on the in one of your repositories.
So if Sinfig does exist, for instance, in the Fedora Extras repository, like RPMfusion
or something, and it's the older version, let's say it's 0.5, I'm making up these version
numbers.
I think I'm in the ballpark, but I could be wrong about them.
But let's say it's 0.5, the new version is 0.6, it's going to compare those two and if
you've just installed 0.6 manually and Yum sees 0.5 on the repository, its job is to make
those two version numbers match.
So it's going to obviously try to actually downgrade you from 0.6 to 0.5 and that would
be an issue for you probably.
So you need to blacklist the Sinfig package that you have installed yourself.
So you need to take ownership of that on your own and resolve that, yes, you know that
it is a newer version than what is available online, but that you are going to keep it updated
or just kind of manage it yourself.
The way to take ownership of a package would be to enter it as an exclude in your Yum.conf.
Yum.conf lives in slash Etsy, not surprisingly.
And so if we again, we're just hanging out as root in this episode, hope you don't mind.
Do a Vim space slash Etsy slash Yum.conf.
And it's a pretty simple conf file to be honest, it kind of has some really obvious stuff
location of the log file, the GPG check, whether it's going to do it or not, simple stuff
like that.
This isn't where the repositories are usually listed.
That's in a different folder slash Etsy slash Yum.repos.d, but it is the correct place for
the excludes.
So all you have to do to exclude something is add a line at the bottom of your conf file
where at the bottom of the active portion of it, the bottom of it is a bunch of commentary.
So I usually avoid that, but right under for instance, install underscore or install
only underscore limit equals three, which I don't even know what that means.
I type in exclude equals and then the name of the package.
So sinfig and actually I'm just going to go ahead and do a wild card RPM.
So if it's a sinfig, something RPM, exclude that from being managed by Yum.
And I might also do that for ffimpeg if I've compiled my own ffimpeg, which wouldn't
surprise me space.
It's just a space, the limited list of all the packages that you do not want Yum to
manage for you.
Now, you can actually override your own excludes interestingly.
So if you know that there's an exciting new version of sinfig out and yes, it's in the
fedora 16 repository or fedora 18, whatever you're upgrading to, or you just decide that
you're tired of dealing with the burden of managing some package and you decide that
you want Yum to go ahead and do an update.
And if there's new stuff, even in your excludes, then go for it.
Then you can do a Yum update dash dash or you know, Yum, well, yeah, I guess it would
be update really or it could be distribution dash synchronization if you're doing a huge
upgrade kind of thing.
But point being, Yum update space dash dash disable excludes, oh, that's one word, equals
in this case all because I haven't defined which repository, you know, I haven't gone
into each repository and said, okay, I want you to exclude this package from this repository
stuff like that, which you can do in the Yum repo directory, but we're not doing that.
So, and I don't really actually do that myself.
So I just say disable excludes equals all and then it goes through the typical Yum update
process or upgrade process, whatever I'm doing, update, whatever.
And it ignores the excludes that I've delineated.
In real life, I think I've done this once.
Usually if I exclude something, I really want it excluded.
One of the commands or sub commands that I use quite frequently actually is Yum Deplist.
Yum Deplist in my mind is just hugely helpful because I'm always cheating on Slackware
and grabbing RPMs from Fedora.
So if I'm from the Fedora repository, so if I look at a Fedora RPM on Fedora and I do
like a Yum Deplist space, whatever, in this case, let's just go ahead and do public in because
that's the one that I've been dealing with lately and I'll pipe that through less because
it's a long list, then it shows you all of the, it shows you the package, which package
is talking about, in this case, public in dot no arch 2.5-2FC15, tells you every single
dependency that that package relies upon.
So if you are doing something like what I do where you're stealing RPMs shamelessly
from the Fedora repositories, Deplist is great because it tells you exactly what you're
going to need in order to get the thing to actually install on your system wherever
you're installing it.
In my case, it would be Slackware via the RPM to TGZ command.
So Deplist is hugely helpful, not really all that important if you're just doing it on
Fedora because Yum is going to resolve all those dependencies for you anyway.
A couple of things great for automation would be the Assume Yes flag, that's dash dash
assume yes, all one word, that obviously assumes yes to any question that Yum might be prompted
to ask you.
And then there's the dash dash skip dash broken, which skips any packages with problems
that, if there's a problem with like resolving a dependency or something, it'll just skip
that package rather than tell you that it can't install anymore and quit.
So those are two good ones for those times that you're not doing a group install or maybe
you are and you're going to walk away from the system.
You know, you've got this big chunk of stuff that you're going to install, you're going
to walk away, go to bed, get up in the morning and have a nice new system.
The thing to do there would be to have those flags turned on probably unless you want
it to stop after like the first package that has one little problem with it.
There are other commands for Yum.
There are a couple of more, I've actually covered a lot of them.
There are still more.
I don't use them so I'm not going to go into them now and pretend like I know what they
do.
I'm going to read you the Yum help results and just kind of give you a one sentence summary
but that's silly.
So those are the commands that I know and love.
Those are the ones that I have either used in a memorable situation or use all the time.
One cool one is kind of that I kind of play around with, sometimes as Yum Shell.
Not that big of a deal really, it just drops you down to a prompt where you can then
not type in Yum Space, group install or whatever.
You just type in just the command.
So if you want a Yum list, you just type in List because you're in the Yum Shell already.
So that's kind of fun I guess to play around with, not that big of a deal, but just so
you know that is there.
Other than that, that's Yum.
That's the big front end for RPM.
It's a, like I say, it's pretty user friendly.
It's quite forgiving, even in things like capitalization, sometimes in the group, the
group installs, you can miss a couple of capitals and it won't break, it doesn't care.
So it's easy to use.
It's fun to use and it's effective.
I probably should mention Yum remove and Yum erase those, as far as I know are the same
thing I could be wrong, erase might be a lot more complete than remove.
I use Yum remove.
So if you want to remove a package that you've installed or that has been installed along
with a group, for instance, a group install that you didn't really want, you can always
do a Yum remove name of that package and that will remove it after your confirmation.
So that's it.
That's Yum.
Hope you enjoy it.
Be sure that if you're going to do Fedora, you obviously want to do a Yum update pretty
early on after installing because of the pace of the development.
And you'd also want to go over to rpmfusion.org and add those repositories probably because
that has a lot more packages and a lot of cool stuff in there.
So hope that helps you if you use Yum and aren't really too clear on some of the functionality
of it and hope it interests you if you've never used it and have been curious.
Thanks for listening.
Bye.
You have been listening to Hacker Public Radio where Hacker Public Radio does our
work.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by a HBR listener by yourself.
If you ever consider recording a podcast, then visit our website to find out how easy
it really is.
Hacker Public Radio was founded by the Digital.Pound and the Empanomical and Computer
Club.
HBR is funded by the binary revolution at binref.com.
All binref projects are crowd-responsive by Lina Pages.
From shared hosting to custom private clouds, go to LinaPages.com for all your hosting
needs.
Unless otherwise stasis, today's show is released under a creative commons, attribution,
share a line, free those own license.