Merge ~larsks/cloud-init:bug/1647118 into cloud-init:master

Proposed by Lars Kellogg-Stedman
Status: Merged
Merged at revision: a3daf184fd47dede8d91588281437453bd38fc1c
Proposed branch: ~larsks/cloud-init:bug/1647118
Merge into: cloud-init:master
Diff against target: 30 lines (+12/-7)
1 file modified
cloudinit/distros/rhel.py (+12/-7)
Reviewer Review Type Date Requested Status
Scott Moser Needs Information
Review via email: mp+312425@code.launchpad.net

Description of the change

    Recent fedora releases use "dnf" instead of "yum" for package
    management. While there is a compatible "yum" cli available, there's
    no guarantee that it will be available.

    With this patch, cloud-init will check for /usr/bin/dnf and use that
    if it exists instead of yum.

To post a comment you must log in.
Revision history for this message
Scott Moser (smoser) wrote :

How far back does dnf support go?
1 inline question.

review: Needs Information
Revision history for this message
Lars Kellogg-Stedman (larsks) wrote :

dnf was introduced in Fedora 18 (and has been the default since 22).

Revision history for this message
Scott Moser (smoser) wrote :

Lars,
did you see the question in line ?

Any reason to not use util.which('dnf') ?

Revision history for this message
Lars Kellogg-Stedman (larsks) wrote :

I missed the inline question, sorry!

If dnf isn't /usr/bin/dnf, I'm not sure what that says about the environment. I would leave it as is unless there is a use case that is "use dnf even when it isn't actually the system package manager".

Revision history for this message
Scott Moser (smoser) wrote :

But why hard code a path to /usr/bin/dnf ?
Why not allow that to be /usr/sbin/dnf or /usr/local/bin/dnf
Perhaps the system is built with dnf from upstream source and installed into /usr/local/bin, or the package maintainer decides it should go in /bin.

The chance for failure in the strict "must be named /usr/bin/dnf" is if the program is not installed there. The chance for failure in my suggested solution (trust the PATH), is name collision (a program in the PATH is named 'dnf' but is a different thing).

I've never understood why anyone would want to insist on a path of a program (/bin/ip or /bin/ls rather than just 'ls' and 'ip').

If you dont have an example likely name collision then i'd prefer util.which and let the administrator get their path set correctly.

Revision history for this message
Scott Moser (smoser) wrote :

I merged this, but used util.which('dnf') rather than os.path.isfile(/usr/bin/dnf).

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1diff --git a/cloudinit/distros/rhel.py b/cloudinit/distros/rhel.py
2index e574e1b..f0e41f7 100644
3--- a/cloudinit/distros/rhel.py
4+++ b/cloudinit/distros/rhel.py
5@@ -202,13 +202,18 @@ class Distro(distros.Distro):
6 if pkgs is None:
7 pkgs = []
8
9- cmd = ['yum']
10- # If enabled, then yum will be tolerant of errors on the command line
11- # with regard to packages.
12- # For example: if you request to install foo, bar and baz and baz is
13- # installed; yum won't error out complaining that baz is already
14- # installed.
15- cmd.append("-t")
16+ if os.path.isfile('/usr/bin/dnf'):
17+ LOG.debug('Using DNF for package management')
18+ cmd = ['dnf']
19+ else:
20+ LOG.debug('Using YUM for package management')
21+ # the '-t' argument makes yum tolerant of errors on the command
22+ # line with regard to packages.
23+ #
24+ # For example: if you request to install foo, bar and baz and baz
25+ # is installed; yum won't error out complaining that baz is already
26+ # installed.
27+ cmd = ['yum', '-t']
28 # Determines whether or not yum prompts for confirmation
29 # of critical actions. We don't want to prompt...
30 cmd.append("-y")

Subscribers

People subscribed via source and target branches