[DEPRECATED] YUM package manager

Last update: Dec 20, 2022

Related tags

Package Management yum

Overview

⛔ This project is deprecated. Please use DNF, the successor of YUM.

YUM

Yum is an automatic updater and installer for rpm-based systems.

Included programs:

/usr/bin/yum		Main program

Usage

Yum is run with one of the following options:

update [package list]

If run without any packages, Yum will automatically upgrade every currently installed package. If one or more packages are specified, Yum will only update the packages listed.
install <package list>

Yum will install the latest version of the specified package (don't specify version information).
remove <package list>

Yum will remove the specified packages from the system.
list [package list]

List available packages.

See the man page for more information (man yum). Also see:

web page: http://yum.baseurl.org/
wiki: http://yum.baseurl.org/wiki

3.2.X Branch - yum-3_2_X
      Starting commit is roughly: a3c91d7f6a15f31a42d020127b2da2877dfc137d
         E.g. git diff a3c91d7f6a15f31a42d020127b2da2877dfc137d

Building

You can build an RPM package by running:

$ make rpm

Note: Make sure you have mock and lynx installed.

Development

You can run Yum from the current checkout in a container as follows (make sure you have the podman package installed):

$ make shell

This will first build a CentOS 7 image (if not built already) and then run a container with a shell where you can directly execute Yum:

[root@bf03d3a43cbf /] yum

When you edit the code on your host, the changes you make will be immediately reflected inside the container since the checkout is bind-mounted.

Warning: There's a (probably) bug in podman at the moment which makes it not see symlinks in a freshly created container, which, in turn, makes Yum not see the /etc/yum.conf symlink when it runs for the first time. The workaround is to touch /etc/yum.conf or simply re-run Yum.

Note: When you exit the container, it is not deleted but just stopped. To re-attach to it, use (replace the ID appropriately):

$ podman start bf03d3a43cbf
$ podman attach bf03d3a43cbf

Comments

Don't crash on invalid repoid from yumdb

Ensure the ui_from_repo property always returns ascii-only strings.

Previously, if the yumdb had been tampered with and a repoid was corrupted for some reason so that it contained non-ascii chars, we could end up reading it and then crash on an implicit conversion to unicode, e.g. in output.fmtColumns().

We could also explicitly convert the data passed to fmtColumns() but that may not fix this completely as we couldn't guarantee that, with the same corrupted repoid, such an implicit conversion wouldn't happen elsewhere. Likewise, doing the conversion in ui_from_repo and returning a unicode string may cause an implicit conversion elsewhere.

opened by dmnks 15

install command will return error code 1 if package is already installed

A lot of installation scripts rely on exit code of commands, and it will exit if any of subcommands has non-zero exit code. Yum may return error code (1) in case package is already installed (imho it is not an error)

Example:

Step 1 (first install):

yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm; echo $?
...
Installed:
  epel-release.noarch 0:7-11                                                                                                                                                                                                               

Complete!
0

Step 2 (install the same package):

yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm; echo $?
...
/var/tmp/yum-root-dE0FBq/epel-release-latest-7.noarch.rpm: does not update installed package.
Error: Nothing to do
1

Step3 (wrong path):

yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch__BUG__.rpm; echo $?
Loaded plugins: fastestmirror
Cannot open: https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch__BUG__.rpm. Skipping.
Error: Nothing to do
1

Suggestion:

A) return 0 exit code (no_error) in _already_installed_case or B) use different error exit code

Alt solutions I found:

1. use localinstall:

will return 0, but it also will return 0 in wrong cases,
like:

yum -y localinstall https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch_BUG.rpm || echo $?
Loaded plugins: fastestmirror, versionlock
Cannot open: https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch_BUG.rpm. Skipping.
Nothing to do
0

2. use reinstall:

works fine, but it will REINSTALL it every time (trade off: at least time)

Reference:

https://github.com/rpm-software-management/yum/blob/master/yum/init.py#L5654

opened by 0x7162 13

depsolve: penalize conflicting provider. BZ 1480065
When there are multiple providers available for a requirement, yum would happily pick the one that the requiring package also has a "Conflicts:" on (via another virtual provide), failing to resolve the transaction.

Example:

foo requires bar and conflicts my-bar

bax provides bar

bay provides bar, my-bar

Yum might decide to pick bay, only to fail due to the conflict with foo later in the process.

This commit fixes that by penalizing such a provider so that it's unlikely for it to be selected during depsolving.
opened by dmnks 9
Yum history always shows user as System in AIX

yum history

ID | Command line | Date and time | Action(s) | Altered

272 | erase -y bison | 2017-06-09 03:24 | Erase | 1 EE 271 | install -y bison | 2017-06-09 03:24 | Install | 1 EE 270 | erase -y git | 2017-06-09 02:22 | Erase | 1 269 | install -y git | 2017-06-09 02:22 | Install | 1 268 | erase -y git | 2017-06-08 21:55 | Erase | 1 267 | install make | 2017-06-07 09:54 | Install | 1 EE 266 | install subversion | 2017-06-07 09:49 | Install | 1 265 | install httpd | 2017-06-07 09:48 | Install | 2 EE 264 | install tla | 2017-06-07 09:44 | Install | 3 EE 263 | install bash curl expat | 2017-06-07 09:44 | Update | 2 EE 262 | install coreutils curl-d | 2017-06-07 09:43 | Install | 1 261 | erase grep-3.0-1.ppc | 2017-06-07 06:41 | Erase | 1 260 | erase -y pcre | 2017-06-07 03:00 | Erase | 1 259 | install -y pcre | 2017-06-07 03:00 | Install | 1 258 | install grep | 2017-06-07 02:09 | Install | 1 257 | erase -y pcre | 2017-06-07 01:38 | Erase | 3 EE 256 | erase -y vim | 2017-06-07 01:10 | Erase | 1 255 | install -y vim | 2017-06-07 01:09 | I, U | 2 254 | erase -y vim | 2017-06-07 00:37 | Erase | 1 253 | install -y vim | 2017-06-07 00:37 | Install | 1 history list

(0) root @ aixoss-automation-2: 6.1.0.0: /opt/freeware/etc/yum/repos.d

yum history info 263

Transaction ID : 263 Begin time : Wed Jun 7 09:44:04 2017 Begin rpmdb : 107:4862ad7227bc760f3d3f5f0c4cf3c4410c7ff593 End time : 09:44:15 2017 (11 seconds) End rpmdb : 107:a3665a21e5b27567f29a034aa57fe2870fed5222 User : System Return-Code : Success Command Line : install bash curl expat gettext less perl python rsync zlib Transaction performed with: Installed yum-3.4.3-4.noarch installed Packages Altered: Updated bash-4.3.30-1.ppc @?AIX_Toolbox_local Update 4.4-1.ppc @AIX_Toolbox_local Updated less-481-1.ppc @?AIX_Toolbox_local Update 487-1.ppc @AIX_Toolbox_local

opened by ayappanec 8
Print a disk usage summary on "yum clean all". BZ 1481220

Replace the confusing "rm -rf" hint with actual info on how much data is still left behind in the cache.

This commit also removes the "Cleaning up everything" message since "everything" was often understood by users as "everything ever cached".

opened by dmnks 7
skipbroken: don't remove old pkg on dep problems

This fixes a typo in f8c15289427c24130a7cdf5bf2f9eb524fc3fa19 that caused the patch to be ineffective. The problem was that we were storing a txmbr in TransactionMember.depends_on later in the function, while we expect package objects there.

opened by dmnks 7
yum-cron: reintroduce days_of_week parameter

In previous versions of yum_cron we had available to us the days_of_week parameter. This patch reintroduces that behavior, and adds the default days_of_week setting in the sample configuration files.

opened by whereismyjetpack 6
Support on python3

Hi, python2 is going to be deprecated in the upcoming year. I have widely used the yum sdk for my own development. I would like to ask for the publish on python3 for this yum sdk. Thank you!

opened by RyanSiu1995 4
Fix for 'history package-list'

The 'yum history package-list package-name' fails to work when transactions for that package are greater than 128(PATTERNS_INDEXED_MAX). This fixes the SQL query.

opened by upadhyeammit 4
yum-cron emits messages even with debuglevel=-4
I have enabled yum-cron to make some servers self-maintain as much as possible. But in case they don't, it's not the end of the world (regular manually initiated yum updates will take care of things, in case automation has failed).

Therefore, I don't want to get error mails from yum like this:

/etc/cron.hourly/0yum-hourly.cron: Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 error was 14: HTTPS Error 503 - Service Unavailable

I only ever want to hear from yum-cron, if it runs into rpm database corruption, or something of that severity.

Consequently, I've adjusted /etc/yum/yum-cron-hourly.conf and /etc/yum/yum-cron.conf, so that emit_via = debuglevel = -4

Still, I get error mails like the above quoted once in a while. I'm seeing this on some CentOS 7.2 servers. I have seen something similar on RHEL servers (but on the RHEL servers, I've simply stopped using yum-cron, in order to cut down on mail-noise).

I believe it's due to the _getMetalink method in yum/yumRepo.py. It prints an error message without considering debuglevel. I don't know it is best fixed, though.

A way to reproduce the error: Adjuste /etc/yum/yum-cron-hourly.conf, asking yum-cron to download updates, but keep silient (see above) with a temporary iptables rule which drops packets to port 443/tcp. Run /etc/cron.hourly/0yum-hourly.cron (For the sake of testing, it's also nice to have random_sleep=0, so that calling /etc/cron.hourly/0yum-hourly.cron doesn't start by sleeping for a while.)
opened by troelsarvin 4
save_ts: fix string concat bottleneck. BZ 1600383

Previously, the way we built the transaction dump was quite inefficient (appending to a string in a number of for-loops). This caused a major delay in Anaconda during the depsolve phase when a large transaction was selected (~80 seconds for a "Server with GUI" selection including all Add-Ons in a RHEL-7.6 VM).

This commit uses a more efficient method [1] in those for-loops that involves appending to a list instead. This cuts down the depsolve time quite a bit (to ~20 seconds according to my tests).

[1] https://wiki.python.org/moin/PythonSpeed/PerformanceTips#String_Concatenation

opened by dmnks 3
ImportError: cannot import name exception2msg

hi, I encountered this error while installing yum. Could you help me ?

Traceback (most recent call last): File "/usr/bin/yum", line 28, in import yummain File "/usr/share/yum-cli/yummain.py", line 32, in from yum.i18n import utf8_width, exception2msg ImportError: cannot import name exception2msg

opened by bultiful 0

yum gets deadlocked/hung up (indefinitely) waiting for urlgrabber-ext-down

While I can appreciate that YUM is now deprecated, it's still the main package manager for EL7, which is where I am running into an issue with it just hanging indefinitely, until it is killed.

The process tree looks like this:

 8702 ?        S      0:05  |       \_ /usr/bin/python /usr/bin/yum -y --disablerepo=* --enablerepo=repo.dc.hpdd.intel.com_repository_*,build.hpdd.intel.com_job_daos-stack* install --exclude openmpi daos-1.1.2.1-1.5456.g02ce0510.el7.x86_64 daos-client-1.1.2.1-1.5456.g02ce0510.el7.x86_64 daos-tests-1.1.2.1-1.5456.g02ce0510.el7.x86_64 daos-server-1.1.2.1-1.5456.g02ce0510.el7.x86_64 openmpi3 hwloc ndctl fio patchutils ior-hpc-daos-0 romio-tests-cart-4-daos-0 testmpio-cart-4-daos-0 mpi4py-tests-cart-4-daos-0 hdf5-mpich2-tests-daos-0 hdf5-openmpi3-tests-daos-0 hdf5-vol-daos-mpich2-tests-daos-0 hdf5-vol-daos-openmpi3-tests-daos-0 MACSio-mpich2-daos-0 MACSio-openmpi3-daos-0 mpifileutils-mpich-daos-0
 8705 ?        S      0:00  |           \_ /usr/bin/python /usr/libexec/urlgrabber-ext-down
 8711 ?        S      0:00  |           \_ /usr/bin/python /usr/libexec/urlgrabber-ext-down
 8712 ?        S      0:00  |           \_ /usr/bin/python /usr/libexec/urlgrabber-ext-down

The status of the processes are:

# /tmp/strace -f -p 8702
/tmp/strace: Process 8702 attached
wait4(8711, ^C/tmp/strace: Process 8702 detached
 <detached ...>
# /tmp/strace -f -p 8705
/tmp/strace: Process 8705 attached
read(0, ^C/tmp/strace: Process 8705 detached
 <detached ...>
# /tmp/strace -f -p 8711
/tmp/strace: Process 8711 attached
futex(0x1444c90, FUTEX_WAIT_PRIVATE, 2, NULL^C/tmp/strace: Process 8711 detached
 <detached ...>
# /tmp/strace -f -p 8712
/tmp/strace: Process 8712 attached
futex(0x2174c90, FUTEX_WAIT_PRIVATE, 2, NULL^C/tmp/strace: Process 8712 detached
 <detached ...>

which to me looks like 8702, 8711 and 8705 are deadlocked all waiting/blocked on each other.

opened by brianjmurrell 6

Sender email address does not appear to be treated the same way for the envelope level as it is for email headers
Let's assume that the system is named cheetah.

It appears that the logic used to replace root@localhost with root@cheetah works as intended for the email headers, but does not apply to the address used as the sender address (the envelope) when sending the email message.

This code:

https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/yum-cron/yum-cron.py#L244-L247

appears to replace root@localhost with root@cheetah and store the result in domain. The domain variable is then used here:

https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/yum-cron/yum-cron.py#L247 to form msg['From'].

We can see here:

https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/yum-cron/yum-cron.py#L254

that the msg type is converted to a string to form the complete email headers/body (I may be butchering this description) as the last argument to the s.sendmail() call.

The first part of the s.sendmail() call appears to use the email_from value as-is without any conversion, so if the configuration has root@localhost, then this is used as-is for the first argument in the s.sendmail() function call.

Is this intentional?

Looking here:

https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/etc/yum-cron.conf#L33-L36

and here:

https://github.com/rpm-software-management/yum/blob/f8616a2d6e22705371fe6ba47597238d3d1dc2f1/etc/yum-cron.conf#L50-L59

I don't see this behavior documented as intentional.

Is this a documentation problem or is the s.sendmail() function call intended to be called this way:

s.sendmail(msg['From'], self.opts.email_to, msg.as_string())
opened by atc0005 0
Avoiding compatibility errors with python 3

I know that yum will be deprecated, so no python 3 support is expected. The best thing to do would be to change all scripts from #!/usr/bin/python to #!/usr/bin/python2.7 This would give people freedom to choose default version of python without errors

opened by LorenzoSacchi 3

yum-builddep not abiding by BuildRequires: package range

A packaging fubar was made and a package was made with a pre-release tag in it without using the ~ indicator. So now my repo has foo-2.0.0a1 in it. That fubar was fixed and foo-2.0.0~a1 is now also in the repository.

But now I want to update another package to use the proper foo package. So I've added to it's spec BuildRequires: foo < 2.0.0a1 and that works and selects foo-2.0.0~a1 with yum-builddep.

$ sudo yum-builddep bar.spec 
...
Getting requirements for bar.spec
 --> foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Running transaction check
---> Package foo-devel.x86_64 0:2.0.0~a1-1.git.4871023.el7 will be installed
--> Processing Dependency: foo(x86-64) = 2.0.0~a1-1.git.4871023.el7 for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Processing Dependency: libfoo.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Processing Dependency: libfoo_hl.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Processing Dependency: libfoo_util.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Processing Dependency: libna.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Running transaction check
---> Package foo.x86_64 0:2.0.0~a1-1.git.4871023.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=================================================================================================================================================
 Package                           Arch                       Version                                          Repository                   Size
=================================================================================================================================================
Installing:
 foo-devel                         x86_64                     2.0.0~a1-1.git.4871023.el7                       my_repo                      58 k
Installing for dependencies:
 foo                               x86_64                     2.0.0~a1-1.git.4871023.el7                       my_repo                     103 k

Transaction Summary
=================================================================================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 161 k
Installed size: 597 k
Is this ok [y/d/N]:

However there are also older versions of foo and I want to ensure that at least a minimum of my new foo-2.0.0~a1-1.git.4871023.el7 package is installed, so I add a BuildRequires: foo-devel >= 2.0.0~a1 to bar.spec. But yum-builddep seems unable to handle that:

$ sudo yum-builddep bar.spec 
...
Getting requirements for bar.spec
 --> foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
 --> foo-devel-2.0.0a1-0.8.git.4871023.el7.x86_64
--> Running transaction check
---> Package foo-devel.x86_64 0:2.0.0~a1-1.git.4871023.el7 will be installed
--> Processing Dependency: foo(x86-64) = 2.0.0~a1-1.git.4871023.el7 for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Processing Dependency: libfoo.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Processing Dependency: libfoo_hl.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Processing Dependency: libfoo_util.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
--> Processing Dependency: libna.so.2()(64bit) for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
---> Package foo-devel.x86_64 0:2.0.0a1-0.8.git.4871023.el7 will be installed
--> Processing Dependency: foo(x86-64) = 2.0.0a1-0.8.git.4871023.el7 for package: foo-devel-2.0.0a1-0.8.git.4871023.el7.x86_64
--> Running transaction check
---> Package foo.x86_64 0:2.0.0~a1-1.git.4871023.el7 will be installed
--> Processing Dependency: foo(x86-64) = 2.0.0~a1-1.git.4871023.el7 for package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64
---> Package foo.x86_64 0:2.0.0a1-0.8.git.4871023.el7 will be installed
--> Finished Dependency Resolution
Error: Package: foo-devel-2.0.0~a1-1.git.4871023.el7.x86_64 (foo)
           Requires: foo(x86-64) = 2.0.0~a1-1.git.4871023.el7
           Available: foo-1.0.1-13.el7.x86_64 (my_other_repo)
               foo(x86-64) = 1.0.1-13.el7
           Available: foo-1.0.1-17.el7.x86_64 (my_other_repo)
               foo(x86-64) = 1.0.1-17.el7
           Available: foo-1.0.1-21.el7.x86_64 (my_other_repo)
               foo(x86-64) = 1.0.1-21.el7
           Available: foo-2.0.0~a1-1.git.4871023.el7.x86_64 (my_repo)
               foo(x86-64) = 2.0.0~a1-1.git.4871023.el7
           Available: foo-2.0.0a1-0.2.git.c2c2628.el7.x86_64 (my_other_repo)
               foo(x86-64) = 2.0.0a1-0.2.git.c2c2628.el7
           Available: foo-2.0.0a1-0.3.git.c2c2628.el7.x86_64 (my_other_repo)
               foo(x86-64) = 2.0.0a1-0.3.git.c2c2628.el7
           Available: foo-2.0.0a1-0.4.git.5d0cd77.el7.x86_64 (my_other_repo)
               foo(x86-64) = 2.0.0a1-0.4.git.5d0cd77.el7
           Available: foo-2.0.0a1-0.5.git.ad5a3b3.el7.x86_64 (my_other_repo)
               foo(x86-64) = 2.0.0a1-0.5.git.ad5a3b3.el7
           Available: foo-2.0.0a1-0.6.git.299b06d.el7.x86_64 (my_other_repo)
               foo(x86-64) = 2.0.0a1-0.6.git.299b06d.el7
           Available: foo-2.0.0a1-0.7.git.41caa14.el7.x86_64 (my_other_repo)
               foo(x86-64) = 2.0.0a1-0.7.git.41caa14.el7
           Installing: foo-2.0.0a1-0.8.git.4871023.el7.x86_64 (my_other_repo)
               foo(x86-64) = 2.0.0a1-0.8.git.4871023.el7
           Available: foo-1.0.1-9.el7.src (my_other_repo)
               Not found
           Available: foo-1.0.1-12.el7.src (my_other_repo)
               Not found
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Is my understanding of being able to use:

BuildRequires: foo-devel < 2.0.0a1
BuildRequires: foo-devel >= 2.0.0~a1

to enforce a version range not correct? I am sure I have seen this done and done this myself in the past.

I even tried:

BuildRequires: foo-devel < 2.0.0a1
BuildRequires: foo-devel > 1.9

to ensure it was not a problem with the pre-release version with the ~ in it.

opened by brianjmurrell 3

Owner

GitHub

OS-agnostic, system-level binary package manager and ecosystem

Conda is a cross-platform, language-agnostic binary package manager. It is the package manager used by Anaconda installations, but it may be used for

5.1k Dec 30, 2022

OS-agnostic, system-level binary package manager and ecosystem

Conda is a cross-platform, language-agnostic binary package manager. It is the package manager used by Anaconda installations, but it may be used for

5.1k Jan 7, 2023

The Fast Cross-Platform Package Manager

The Fast Cross-Platform Package Manager part of mamba-org Package Manager mamba Package Server quetz Package Builder boa mamba Mamba is a reimplementa

4k Dec 30, 2022

Conan - The open-source C/C++ package manager

Conan Decentralized, open-source (MIT), C/C++ package manager. Homepage: https://conan.io/ Github: https://github.com/conan-io/conan Docs: https://doc

6.5k Jan 5, 2023

A flexible package manager that supports multiple versions, configurations, platforms, and compilers.

Spack Spack is a multi-platform package manager that builds and installs multiple versions and configurations of software. It works on Linux, macOS, a

3.1k Jan 9, 2023

Easy to use, fast, git sourced based, C/C++ package manager.

Yet Another C/C++ Package Manager Easy to use, fast, git sourced based, C/C++ package manager. Features No need to install a program, just include the

31 Dec 21, 2022

The delightful package manager for AppImages

⚡️ Zap The delightful package manager for AppImages Report bug · Request feature Looking for the older Zap v1 (Python) implementation? Head over to v1

368 Jan 4, 2023

Dotpkg - Package manager for your dotfiles

Dotpkg A package manager for your dotfiles. Usage First make sure to have Python

4 Mar 18, 2022

:package: :fire: Python project management. Manage packages: convert between formats, lock, install, resolve, isolate, test, build graph, show outdated, audit. Manage venvs, build package, bump version.

THE PROJECT IS ARCHIVED Forks: https://github.com/orsinium/forks DepHell -- project management for Python. Why it is better than all other tools: Form