[Linux 초보 탈출] DNF (package manager)에 대해 알아 봅시다.

이 포스트는 Fedora Linux를 기준으로 작성되었습니다. 

리눅스를 처음 시작하는 유저들이 흔히 묻는 질문 중에 "리눅스 설치하고 가장 먼저 뭘 배워야 합니까?" 라고 묻습니다.  이떄 제가 늘 하는 말은 "어떤 리눅스를 사용하는데 ? 아.. 그래 ? 그럼 XXX 부터 배워야지~" 라고 말해주곤 하는데, XXX가 뭐냐 하면 바로 해당 리눅스의 기본 패키지 관리자(Package Manager)를 배우라는 것입니다. 

제 아무리 뛰어난 OS를 설치했다 하더라도 프로그램을 설치하거나 설치된 프르그램을 관리할지 모른다면 무슨 의미가 있겠습니까 ? 그래서 가장 먼저 배워야 할 것 중에 하나는 본인이 사용하는 리눅스 배포판의 기본 Package Manager에 대해 알아야 합니다. 

이 번 포스트에서는 Redhat 계열의 리눅스에서 기본으로 사용되는 Package Manager인 DNF에 대해 알아봅니다.  설명을 하는 과정에서 Linux와 관련된 여러 가지 또 알아보게 될 것입니다. 

 

DNF(Dandified YUM)

Linux에는 매우 다양한 배포판(distro) 이 존재합니다.  배포판은 영어로 Distribution 인데, 왜 Distro라고 쓸까 ? Distribution 이라고 표현하면 너무 딱딱하고 발음도 길어서, 짧고 발음하기 쉽게 distro라고 표현을 합니다. 영어권에서 -o로 끝나는 형태는 비공식 줄임말인 경우가 꽤 있습니다. combination의 줄임말 combo, limousine의 줄임말 limo 같은 것들이 있습니다. 

흔히 개념적으로 볼 때, Linux라는 것은 원래는 운영체제의 핵심인 Kernel 만을 의미합니다. 하지만, 우리들이 사용할 수 있는 OS(운영체제)라고 하면 Kenrel 만 있는 것이 아니라 그 밖에 다양한 소프트웨어와 도구들이 있아야 하죠. 이렇듯 Kernel과 그 밖에 운영체제를 구성하기 위해 필요한 라이브러리들과 소프트웨어, 유틸리티 등등을 모두 포함하여 Linux 배포판이라고 칭합니다.  따라서 각각의 배포판들은 특화된 사용 목적, 타깃 사용자 층, 혹은 특정한 목표나 철학을 담아내기 위한 것들로 차별화되어 있습니다. 

Linux 배포판을 구분할 떄, 우리는 계열(Family) 그러니까 족보를 따지는데, 각 배포판의 근원(root)이 뭐냐 하는 것입니다. 대표적으로 Debain, Red Hat,  Arch 등이 있습니다. 이 Root에서 뻗어 나온 것들이 Debian 계열에서는 Debian, Ubuntu, Mint, Pop!_OS, Kali 가 있고, Red Hat 계열의 대표적인 Distro에는 RHEL(Red Hat Enterprise), Fedora, CentOS, Rocky 등이 있으며, Arch 계열에서는 Arch, Manjaro, EndeavourOS 등이 있습니다. 

각 배포판들은 나름의 패키지 관리자를 갖고 있는데, Debian 계열에서는 APT(Advanced Package Tool), Red Hat 계열에서는 DNF(Dandified YUM), Arch 계열에서는 Pacman(Package Manager) 를 사용합니다. 

Fedora를 사용하다가 Ubuntu를 사용할 때, 혹은 그 반대의 경우라도 가장 불편한 것 중에 하나가 바로 이 package manager가 바뀜으로 해서 느끼는 어색함인 경우가 많습니다. 

정리를 해 보면, 이번 포스트에서 다룰 DNF package manager는 Red Hat 계열에서 사용하는 대표 package manager 인 것이죠. 

DNF는 Dandified YUM의 약자입니다. 직역을 해 보자면 "세련된 YUM" 이라고 할 수 있겠죠? 그럼 YUM은 뭐냐? DNF 이전에 Red Hat 계열에서 통용되던 package manager 입니다. Red Hat 계열에서는 .rpm 확장자를 사용하는 package를 이용하는데, RPM은 Red Hat Package Manager의 약자로 macOS의 .pkg 나 Windows의 .msi 등과 같이 설치할 소프트웨어 세트와 함께 설치에 필요한 Meta Data(설치 지침, 의존성 정보)등을 포함하고 있는 파일입니다. 

DNF는 YUM의 성능 개선 버전인 셈인데, YUM(Yellow Updater, Modified)은 그 전신인 Yellowdoc Linux에서 사용하던 Yellowdoc Updater 패키지 관리자(YUP)에서 유래한 것입니다. Yellowdoc Linux는 PowerPC에서 구동할 수 있는 Linux 배포판으로 당시를 회상해 보면, Apple의 Macintosh 나 Sony의 PS3 에서 사용했었습니다. 여기서도 RPM을 사용했었죠.  암튼, 이 YUP을 수정 업그레이드 시킨 것이 YUM 이였고.. 이를 계승하여 보다 복잡해진 의존성 문제 해결, 대량의 package의 신속하게 처리, 보다 적은 리소스 소모 등의 성능 및 기능 확장판이 바로 DNF 입니다. 과거부터 사용해 오던 사용자들을 배려하여 여전히 yum 명령을 사용할 수 있지만, 실질적으로 yum은 dnf에 symbolic link로 연결되어 있어 실제적으로는 dnf를 사용합니다. 

yum은 /usr/bin 폴더에 위치하지만 실제로는 dnf의 symbolic link 이다.

패키지 관리자가 갖는 가장 강력한 장점은 의존성관련 처리를 해준다는 것입니다. dnf를 통해 특정 패키지를 설치하면 dnf는 패키지에 기록된 의존성 관련 정보를 확인하고 이를 이용하여 자동으로 해당 패키지를 사용하기 위해 필요한 관련 패키지들을 설치해 줍니다. 과거 이런 기능이 없었던 때에는 일일이 사용자들이 관련 패키지들을 설치하고 관리해야 했기 때문에 굉장히 힘들었었는데, dnf 가 이를 알아서 관리해 주기 때문에 굉장히 편리해진 셈입니다. 서로 다른 패키지들이 동일한 의존성 패키지를 필요로 할 때 만일 의존성 패키지의 버전을 서로 다르게 원할 경우라도 dnf 는 여러 버전의 패키지를 다 설치해 주고 관리합니다. 또한 사용자가 특정 패키지를 제거한 경우 dnf는 자동으로 의존성을 확인하고 필요 없어진 패키지들을 제거할 수 있는 정보를 제공할 수도 있습니다. 이런 각각의 내용은 아래에서 다시 다뤄보게 될 것입니다. 

 

RPM(Red Hat Package Manager)

자, 그럼 .rpm 패키지 파일에 대해 좀 알아봅니다.  DNF가 다루는 rpm 패키지에는 naming 규칙이 있습니다. 

[name]-[version]-[release].[architecture].rpm

# name    : 패키지 이름 , - 을 사용하여 subpackage임을 명시
            ex) samba-devel
# version : 버전 
# release : name + version 을 사용하며, 다시 패키징할 때 번호를 1씩 증가
# architecture : 
  - x86_64  : 64비트 Intel/AMD 프로세서 
  - i686    : 32비트 Intel 호환 프로세사 
  - aarch64 : 64비트 ARM 프로세서 
  - ppc64le : 64비트 PowerPC 프로세서 
  - noarch  : 특정 아키텍쳐어 종속되지 않음(스크립트, 문서 등) 
  - src     : RPM 패키지 소스

상식 차원에서 Arm 은 회사 이름이고, ARM은 아키텍처(기술)를 지칭할 때 사용합니다. 우리나라 신문 기사를 보면, 회사를 지칭할 때 ARM을 쓰는 경우가 많은데, 이건 현재로선 잘못된 것입니다.  물론 완전 엉터리는 아닙니다. 왜냐면 과거에는 회사 이름도 ARM 이였기 때문입니다만, 2017년에 회사는 ARM Holdings를 Arm으로 변경했습니다.  

그래서, 예를 들자면 .rpm 패키지는 아래와 같은 이름으로 배포가 됩니다. 

nano-8.3-3.fc42.src.rpm

name        : nano 
version     : 8.3
release     : 3.fc2 - fedora 42 용 3번째 릴리즈
archtecture : src

rpm 패키지는 repository(저장소)를 통해 배포하는 것이 일반적입니다 

Linux를 설치하면, 설치 디스크나 디스크 이미지에서 기본적은 패키지들을 설치한 후, 인터넷을 통해 배포판이 운영하는 공식 Repository를 통해 업데이트를 하게 됩니다. Fedora의 경우에는 updates, fedora 라는 공식 저장소를 운영하고 있으며, 새롭게 추가된 패키지, 업데이트 소식들을 전용 홈페이지를 통해 확인할 수 있습니다. 공식 저장소에 포함된 모든 패키지들은 Fedora가 엄격한 패키징 가이드라인(Packaging Guideline)을 준수, 철자한 Review를 통해 품질 보증(QA) 프로세스를 유지합니다. 이와는 별도로 Copr(Cool Other Package Repo)라는 커뮤니티 기반의 빌드 서비스 및 커뮤니티 저장소가 운영됩니다. 

.rpm 패키지는 cpio라는 아카이브 형식을 갖춘 일종이 압축파일 입니다 따라서, 만일 rpm 파일을 다운로드 받았다면 rpm2cpio와 cpio를 이용하여 .rpm 파일을 압축해제 할 수 있습니다. 

rpm2cpio test.rpm | cpio -idmv

rpm2cpio 와 cpio를 이용하여 rpm 파일의 압축을 해제한 예

 

패키지 업그레이드, 검색, 설치, 제거

DNF 가 뭔지는 이 정도로 알아보면 될 것 같고, 그럼 이제 실제로 어떻게 사용하는지를 알아봐야겠습니다. 

우선, dnf를 이용할 때는 항상 앞에 sudo 명령어를 붙입니다 sudo(superuser do) 는 사용자 권한을 갖는 유저가 일시적으로 root 권한을 얻어 특정 명령을 실행할 수 있도록 해주는 도구로 Linux 시스템의 권한 관리 및 보안 원칙을 준수하고자 하는 이유 때문입니다. 대부분의 패키지들은 시스템 파일들과 의존성이 있고 따라서 설치도 root 권한으로 접근 가능한 디렉터리에 설치하게 됩니다.  이런 이유로 일반적으로 package를 검색하거나 정보를 확인할 때는 sudo 를 사용하지 않고  dnf만 사용해도 무방하지만, 설치/업데이트/제거 등 실질적으로 변경을 가할 때는 sudo를 사용해야만 합니다. 

sudo를 사용하면 보안관계상 사용자의 비밀번호를 물어보게 되는데, 이것이 불편할 수 있습니다. sudo를 사용할 때 비밀번호를 묻지 않게 하려면, 터미널에서 sudo visudo 명령으로 /etc/sudoers 파일을 열고, 해당 파일의 내용을 확인합니다.  

파일 내용 중에 %wheel ALL=(ALL) NOPASSWORD: ALL 이 주석처리 되어 있다면, 주석을 제거하여 활성화 시키고 저장합니다.

여기서 wheel 이라는 것은 특수 권한을 가진 사용자 그룹을 의미하는 용어입니다. Big Wheel에서 유래된 용어인데, 1970년대 초기 UNIX 시스템에서 사용하던 용어로 큰 영향력 또는 권력을 가진 사람을 의미하는 은어이며,  시스템에서 최고 관리자 권한을 가진 사용자를 지칭합니다.  따라서, 본인의 계정을 wheel 그룹으로 지정하면 sudo 명령을 사용하여 root 권한으로 실행할 수 있는 일들을 할 수 있습니다. 

자신의 계정이 어떤 그룹에 포함되는지를 확인하려면 groups 이라는 명령어를 사용하면 확인할 수 있습니다. 

groups 명령으로 자신이 어떤 그룹에 속해 있는지를 확인할 수 있다.

 Fedora를 사용한다면, 기본적으로 사용자는 wheel 그룹으로 등록이 되어 있지만, 만약 wheel 그룹이 없다면 다음 명령으로 wheel 그룹에 등록할 수 있으며, 그룹 등록 후에는 logout -> login 해야 효력을 발생합니다. 

sudo usermod -aG wheel <계정이름>

# 옵션 a : append (추가)
# 옵샨 G : groups 라는 의미

 

패키지 업데이트  : sudo  dnf  update (또는 upgrade)

가장 흔하게 많이 사용하는 것은 바로 설치된 패키지들을 update 하는 것입니다  sudo dnf update 명령을 내리면 dnf는 시스템에 설치된 repository를 통해 새롭게 업데이트된 패키지들이 있는지의 여부를 확인하고, 있으면 해당 정보를 읽어 온 후 사용자에게 알려 주게 됩니다.

sudo dnf update 의 예

업데이트 목록에는 package 이름과 버전, 자정소 위치, 그리고 설치 크기 정보를 제공합니다. 그리고 사용자에게 업데이트할지의 여부를 물어보게 되지요. 

yum을 사용하던 시절에는 update와 upgrade가 별도로 존재했었지만 dnf 에서는 이 둘 간의 차이가 없으며, 내부적으로는 upgrade로 처리합니다. 일반 패키지를 대상으로 할 때는 update는 그냥 alias(별칭)인 셈입니다.  참고로 Debian 계열의 APT 에서는 update와 upgrade를 명확히 구분합니다. update는 패키지 저장소의 메타데이터(패키지 목록, 버전 정보 등)만 업데이트하고 실제 시스템의 패키지들을 업그레이드하지 않습니다. 실제로 본인의 컴퓨터에 설치된 패키지를 업데이트하려면 upgrade 명령을 사용해야 합니다.  따라서 ubuntu 사용자들은 먼저 update를 한 후, upgade를 해야 합니다. 

하지만, dnf 에서는 구분이 없이 update 던 upgrade이던 동일하게 최신 저장소의 메타데이터를 확인하고 필요한 경우 다운로드하며, 설치된 패키지들을 최신 버전으로 업그레이드할 수 있는 인터페이스를 지원합니다. 

다만, 시스템을 업그레이드할 경우에는 upgrade를 사용해야 합니다.  예를 들어 fedora 41 버전을 사용하고 있는데, fedora 42로 업그레이드를 한다면 이 때는 sudo dnf system-upgrade 라는 명령을 사용합니다.  

dnf의 update가 갖는 특징은 새로운 패키지가 설치될 때는 알아서 종속성이 있는 패키지들을 자동으로 설치를 해 준다는 점

위의 스샷에서 처럼 sudo dnf update를 했을 때, 여러 개의 패키지가 업그레이드 대상으로 리스트 업 되었지만, 사용자는 특정 패키지만 선별적으로 update 할 수 있습니다. 

sudo dnf update <패키지명> <패키지명>

위의 스샷을 예를 들자면, sudo dnf update를 했을 때, 제일 하단에 upgrade를 할 것인지 (y/N)로 물어보는데, 전체를 다 업그레이드하지 않고 특정 패키지만 우선 upgrade 하고자 한다면 N(no)를 선택하여 빠져나온 후, sudo dnf update NetwoekManager 이렇게 패키지 명을 정의해서 해당 패키지만 upgrade 할 수 있습니다.  물론 sudo dnf update fcitx5 fcitx5-hangul 처럼 package 명을 나열하면 해당 패키지들만 한 번에 upgrade 할 수 있습니다. 

update 패키지 중에 kernel 과 관련된 패키지의 경우 주의해야 할 것이 있습니다. kernel 패키지를 업데이트 할 때는, 시간이 꽤 오래 걸립니다. 컴퓨터 환경에 따라 다르겠지만, 수 분 내지 수 십분이 걸릴 수도 있습니다.  커널 패키지는 설 치 후 스크립트(post-install scripts)가 꽤 많이 실행됩니다. 이유는 kernel 과 관련된 모듈, 드라이버, 펌웨어 등에 대한 설치 및 upgrade를 동반할 수 있기 때문입니다. 그래서 시간이 오래 걸린다고 중간에 중단을 시키거나 컴퓨터를 꺼 버리게 되면, 부팅이 되지 않는 황당한 일이 벌어질 수 있습니다. 온전히 upgrade가 마무리 될 때까지 기다려야 하며, 끝난 후에는 아래처럼 kernel이 잘 등록되었는지 확인해야 합니다. 

ls /boot 으로 /boot 폴더를 확인해 보면, kernel 버전 별로 6 종류의 파일이 존재하는 것을 볼을 알 수 있습니다. Fedora의 경우 만일을 위해 3개의 버전을 유지하며, 새로운 kerenl 이 업데이트 되면, 가장 과거의 것부터 제거를 하고 항상 3개 버전을 유지합니다. 업데이트 후에 최신 업데이트 버전이 존재하지 않거나 일부만 포함되어 있다면, 절대 rebooting을 하지 말고 kernel을 다시 update 해야 합니다. 

 

패키지 검색 : sudo  dnf  search <검색 키워드>

패키지를 검색할 때는 search 명령을 사용하면 됩니다.  검색 단계에서는 패키지 명을 정확히 모를 수 있으므로 자신이 찾고자 하는 검색어로 검색을 하면 됩니다. 

vim 이라는 키워드로 검색을 한 경우

검색 키워드는 패키지 이름, 요약, 설명 등 패키지 메타데이터의 정보 전반을 근거로 검색하게 됩니다. 

앞서 설명에서 검색의 경우에는 굳이 sudo를 붙이지 않아도 된다고 설명을 했었지만, 그래도 sudo를 사용하여 검색을 하는 것이 좋습니다. 이유는 sudo는 root 권한이고 sudo를 사용하지 않으면 일반 사용자 권한이기 때문입니다. 이게 뭔 소리냐 하면.. 어쩔 수 없이 패키지를 설치하려면 sudo 를 사용해야 하는데,  그럼 결국 관리할 패키지들의 정보는 root 계정의 저장소에 저장되고 관리된다는 것입니다. 그런데 dnf search를 명령하면 사용자 계정 권한으로 dnf package 정보를 가져오고 관리할 목적으로 사용자 계정 폴더에 또 정보를 저장하게 됩니다. 이건 시간도 오래 걸리고 정보를 이중으로 관리하는 셈이니 어차피 sudo로 설치할 것, 그냥 모두 root 권한으로 사용하는 것이 편하다는 것입니다. 

 

패키지 정보 확인 : sudo  dnf  info <패키지 명>

설치 여부와 관계없이 특정 패키지의 정보를 확인하고 싶다면 info 명령을 사용하면 됩니다. 

boxes-vim 이라는 패키지의 정보를 확인

위의 스샷처럼 info 명령 뒤에 패키지 명을 주면 해당 패키지에 대한 정보를 간략히 보여 줍니다. Available package라는 것은 "설치는 되어 있지 않으므로 설치를 할 수 있다" 는 의미입니다. 이미 설치가 되어 있다면, Installed packages 라고 표시가 됩니다. 보시면 여러 항목들이 있지요. 대부분은 직관적으로 알 수 있는 항목들입니다.

특별히 Epoch(에포크)라는 게 있는데, 이 것은 버전 충돌을 방지하기 위해 만들아 놓은 특수 필드입니다. 만일 공식 패키지가 1.2.3 버전으로 릴리즈가 되었는데, 나중에 알고 봤더니 이 패키지에 문제가 있습니다. 예를 들자면 메타데이터가 잘못되었거나, 종속성 정보가 잘못되었거나 혹은 일부 파일이 빠져 있었다던가. 등등.. 해당 패키지의 upstream version은 바뀐 것이 없으니 버전을 바꿀 수는 없습니다. 하지만 문제를 해결한 버전이라면 이전 패키지의 업데이트 버전으로 배포하여야 하는데, 이럴 때 upstream 버전을 변경하 않고 배포판만 업해서 배포할 목적으로 이 필드가 존재합니다. 따라서, 대부분은 0 이거나 이 필드가 없습니다. 해당 필드가 존재하고 값이 0 이 아니라면 이전 배포 패키지에 뭔가 문제가 있어 다시 배포된 패키지라고 판단하면 됩니다. 

 

패키지 설치 : sudo  dnf  install <패키지 명>

패키지를 새로 설치하려면 install 을 사용합니다. 

nano 패키지를 설치하는 예

위의 스샷은 nano 라는 패키지를 설치하는 예입니다. 설치할 패키지가 nano 딱 한 개 인 것을 보면 추가적으로 설치할 종속성 패키지는 없는 것을 알 수 있습니다. 설치는 711 KiB 이고, 다운로드할 크기도 동일합니다. 하지만 실제 설치될 크기는 3 MiB 임을 알 수 있죠. 그리고, [y/N] 으로 사용자의 선택을 대기합니다. 

여기서 또 상식 하나 알고 갑시다.
파일이나 저장장치의 크기를 말할 때, KB(킬로 바이트), MB(메가 바이트), GB(기가 바이트) 요렇게 표현을 하는데, 언제부턴가 KiB, MiB, GiB 등을 사용하게 됩니다. 컴퓨터는 2진법을 사용하기 때문에 전통적으로 1GB는 1024MB라고 알고 있었습니다. 반면 저장장치 제조사들은 이를 제정 규칙대로 10진법으로 표시했습니다. 원래 KB, MB, GB는 10진법이었기 때문입니다. OS에서 1024로 계산된 결과를 본 사용자들은 1TB 저정장치를 사서 컴퓨터에 달면 저장용량이 적게 표시되는 오해를 하게 되었고, 제조사를 상대로 소송전이 벌어지기도 했죠.. 100개의 사과를 4로 나누면 25이고, 5로 나누면 20 입니다. 표시는 25 또는 20으로 표시되지만 본질인 100개는 변함이 없지요.  그래서 결국 1990년대 후반, 이러한 혼란을 해결하고자 IEC(국제 전기 기술 위원회)에서 KiB, MiB, GiB 같은 이진 접두어를 제정하게 되었고, OS 에서 이를 구분하여 표시하게 됩니다. 물론 지금도 KB, MB,GB로 표시하는 OS들이 있고 여전히 일부에서 혼란은 계속되고 있지요.. 

자 다시 본론으로 돌아와서, 보통 default 값은 대문자로 표기합니다. [y/N] 이므로 사용자가 그냥 Enter키를 치면 설치를 하지 않겠다(No)가 됩니다. 따라서 설치를 하려면 y를 키인 하고 enter키를 처야 합니다. 

설치

y를 키인하고 enter를 치면 위의 스샷처럼 해당 패키지를 설치합니다. 다운로드 > verify > Prepare > Installing > complete 과정으로 진행됩니다. 

verify 단계에서는 파일의 무결성(Integrity)과 진위성(Authenticity)를 확인합니다.  이는 손상되거나 악성 코드가 삽입된 패키지가 설치되는 것을 방지하기 위한 단계입니다. 

prepare transaction 단계는 실제로 설치를 하기 전 필요한 사전 작업을 수행하는 단계로 외존성 패키지를 마지막으로 확인하고 설치된 패키지들 과의 충돌 및 단종(Obsoletes) 문제가 있는지를 최종적으로 판단합니다. 어떤 파일을 어디에 설치할지, symbolic link를 만들어야 하는지의 여부 설치 과정에서 어떤 스크립트가 실행어되어야 할지를 판단합니다.  이를 통해 설치 중에 설치가 중단되거나 오류가 발생되는 등의 무결성을 확정합니다. 

Installing 단계는 실체로 패키지의 설치 파일들을 해당 위치에 복사하고 스크립트를 실행하여 서비스 활성화, 데이터베이스 초기화, 권한 및 소유권 설정 등의 처리를 하게 됩니다. 

만일, repority의 공식 패키지가 아니고 사용자가 임의로 다운로드 받은 .rpm 파일을 install 하고자 한다면 어떻게 해야 할까 ?

공식 또는 비공식 repository가 아닌 .rpm 파일을 설치할 경우에도 동일하게 install 명령을 사용하면 됩니다. 

keymapper 라는 rpm 패키지를 다운로드 받았다.

예를 들어 위의 스샷과 같이 keymapper rpm 패키지를 다운로드하였고 이를 설치하고 싶다면. 아래와 같이 명령합니다. 

sudo dnf install ./keymapper-4.12.3-Linux-arm64.rpm

여타 저장소를 통한 패키지 설치와 동일하지만, 위의 스샷에서 보는 바와 같이 Repository가 commandline 으로 되어 있는 것을 알 수 있습니다. 이 와에 차이는 없고 동일하게 진행됩니다. 

rpm 파일을 직접 설차한 패키지의 info

사용자가 직접 설치한 rpm 패키지의 info를 보면, 역시 From repository 필드가 commandline으로 되어 있는 것을 알 수 있지요.

그럼, 사용자가 직접 설치한 패키지는 어떻게 upgrade를 할까 ?
만일, 개발자가 다음 업데이트 버전을 배포했다면.. 그 버전을 다운로드한 후에 sudo dnf install.. 로 다시 install 을 하면 됩니다. 개별적으로 다운로드한 rpm은 update 정보를 확인할 수 없기 때문에 그냥 install을 하면 dnf 가 알아서 기존에 설치된 패키지와 비교를 하고 업데이트 버전이라는 것을 파악하게 됩니다. 따라서 자연스럽게 upgrade를 하게 됩니다. 

 

패키지 제거 : sudo  dnf  remove <패키지 명>

기존에 설치된 패키지를 제거하고 싶다면 remove 명령을 사용합니다. 

패키지 제거의 예

remove 명령을 내리면, 위의 스샷처럼 제거될 package 정보를 표시하고 사용자의 최종 결정을  대기합니다. 

y를 키인 하고 enter를 치면, 이제 실제 제거를 수행하게 됩니다. 

제거는 prepare, removing 두 단계로 진행됩니다.  각 단계는 install 단계와 동일한 기능을 수행한다고 보면 됩니다. 

remove와 관련하여 좀 더 생각해 볼 것이 있습니다. 

설치된 특정 패키지를 제가할 때, 의존성 때문에 함께 설치된 패키지들이 있을 수 있습니다. 그럼 해당 패키지를 제거하면 함께 설치 되었던 의존성 패키지들도 함께 제거가 되는 것일까 ?  결론은 그럴 수도 있고 그렇지 않을 수도 있습니다. 만일 함께 설치되었던 의존성 패키지들이 다른 설치 패키지에서도 사용된다면 dnf는 이를 확인하고 해당 패키지는 제거 목록에서 제외합니다.  패키지 관리자를 사용하는 잇점이 이런데 있는 것이죠. 

그럼 반대로, 어떤 패키지를 제거하는데, 해당 패키지를 설치할 때 의존성 패키지가 함께 설치된 적은 없습니다. 하지만, 삭제할 패키지가 반대로 다른 설치패키지에서 필요한 것이라면?  이럴 경우에는 해당 패키지가 제거됨으로써, 영향을 받는 패키지들을 모두 삭제하려고 시도 하게 됩니다. 

codec2 패키지를 remove 하려고 시도한 경우

위의 스샷을 보면, codec2라는 패키지를 remove 하는 경우를 보여 줍니다. codec2는 Audio/Video 프로그램들이 사용하는 codec 으로 이 패키지를 제거함으로써 영향을 받는 패키지들을 제시하고 있는 것을 볼 수 있습니다. Removing Dependent packages: 목록은 codec2와 매우 강력한 의존성을 가지고 있기 때문에 codec2를 제거하면 사용할 수 없어서 함께 제거를 할 것이라고 제안한 목록 입니다. 스샷에는 없지만 Removing unused dependencies: 항목도 있는데, 이 섹셕에 열거된 패키지 목록은 해당 패키지를 제거함으로써 시스템의 어떤 패키지도 사용을 하지 않게되는 패키지(이를 보통 "orphan(고아) 라고 표현함) 목록 입니다. codec2와 직접적인 의존성은 없지만, codec2를 제거함으로써 함께 제거되는 패키지들이 있을 수 있고, 이들을 다 제거하게 되면 아무도 사용하지 않게되는 패키지들이 있다는 정보 입니다. 

따라서, 이러한 패키지들은 왠만해서는 제가에 신중헤야 합니다 기존에 사용하던 다양한 영역에서 파급효과가 대단히 크기 때문입니다. 

설치는 가볍게 할 수 있지만, 제거는 신중해야 한다는 의미가 됩니다.  그럼에도 불구하고 해당 패키지를 제거해야 하는 피치 못할 사정이 있다면, 이 경우에는 dnf 를 사용하지 않고 아래와 같이 rpm -e 명령을 사용해서 특정 패키지만 제거할 수 있습니다. 

sudo rpm  -e --nodeps <패키지 명>

하지만, 이렇게 의존성이 높은 패키지를 제거할 경우 dnf에서는 꽤 혼란이 발생할 수 있습니다.  따라서 가급적이면 dnf로 관리된 패키지는 dnf로 계속 관리하는 것이 좋고 의존성이 높은 패키지는 그냥 놔두는 것을 권장합니다. 

 

 

패키지 다운그레이드, 히스토리 관리

자 이제, 일반적인 사용이 아닌 좀 특별한 경우에 대해 알아봅니다. 

패키지 다운그레이드 : sudo  dnf  downgrade <패키지 명>

어떤 패키지를 upgade 했는데, upgade 하기 전까지는 문제가 없었는데 upgrade를 하고 나니 이전과 달리 뭔가 이상해졌습니다. 이럴 경우 이전 버전으로 되돌릴 필요가 있을 수 있는데, 이럴 때 downgrade를 할 수 있습니다. 

우선, 해당 패키지로 downgrade를 할 경우 downgrade가 가용한 버전들이 무엇이 있는지를 확인할 필요가 있을 겁니다.  이럴 때는 list 명령의 --showduplicates 옵션을 사용합니다. 

sudo dnf list --showduplicates <패키지 명>

스샷을 보면 chromium browser에 대해 list showduplicates 옵션을 수행한 결과입니다. 

현재 설치된 것은 138.0.7204.100-1 버전이고, 사용가능한 다른 버전의 패키지가 두 개가 더 있음을 알 수 있습니다. 6998 버전과 7204.157-1  이죠.. 흰색은 과거 버전이고 파란색은 다음 버전을 의미합니다. 

만약 지금 설치한 138.0.7204 버전이 문제가 있어서 과거 버전으로 되돌아가고 싶은데, 만약 바로 직전의 버전으로 되 돌아가고 싶다면. 아래와 같이 downgrade 명령을 사용합니다. 

sudo dnf downgrade <패키지 명>

downgrade의 예

스샷을 보면, 두 개의 package를 이전 버전으로 되돌릴 것임을 알 수 있습니다. 7204.100 버전을 6998.165 버전으로 되돌릴 것이라고 알려주고 있군요.  처리 과정에서 319 MiB 가 소요되며, 298 MiB 만큼 제거할 것이라고 합니다. 그래서 21 MiB 만큼이 더 소요될 것이라 합니다. 

만약 downgrade를 했는데, 여전히 문제가 있어서 그 이전 버전으로 더 되돌아가고 싶다면. 동일하게 계속 downgrade 명령을 내리면 됩니다.  물론 패키지에 따라 바로 직전 버전까지만 관리되는 패키지도 있고, 꽤나 많은 이전 버전을 관리하는 경우도 있습니다. downgrade의 수준은 각 패키지마다 다를 수 있습니다. 

자.. 그러면.. 예를 들어 진짜 특정 패키지를 upgrade 한 후에 문제가 발생하여 어쩔 수 없이 downgrade를 했다고 가정을 해 봅니다. 이 경우 sudo dnf update를 수행하면 해당 package의 다음 버전(문제가 된 그 버전)이 있다며 update 목록에 나타나게 될 것입니다.  이거 보기 싫다고 sudo dnf update를 안 할 수도 없고 말이죠..    이렇게 특정 패키지의 특정 버전을 배제하고 싶다면 update 의 --exclude 옵션을 사용합니다. 

sudo dnf update --exclude=<패키지 명>

--exclude=<패키지 명>을 하면 이후부터는 아예 해당 패키지는 업데이트가 있어도 표시를 해 주지 않습니다. 말 그대로 패키지 update에서 배제를 시키는 것입니다. 

sudo dnf update --exclude=chromium 을 실행한 예

위의 예에서 볼 수 있듯이, --exclude=chromium 으로 update를 요청하면 skip 항목으로 잡혀서 해당 패키지는 update에서 배제시킬 수 있습니다. 하지만, 매 번 update를 확인할 때마다 --exclude 옵션을 다는 것도 귀찮자요.

 

패키지 버전 고정 : sudo  dnf  versionlock <패키지 명>

이럴 경우 versionlock 기능을 사용하면 편리합니다. 
이 방법은 특정 패키지의 버전을 고정(lock) 시키는 것으로 이 기능을 사용하려면 plugs-core 패키지를 설치되어 있어야 하는데, 설치가 안되어 있다면 아래와 같이 설치를 해 줍니다. (아마 기본으로 설치가 되어 있을 겁니다)

sudo dnf install dnf-plugins-core

설치가 된 이후에는 다음과 같이 명령을 내려 특정 패키지의 버전을 고정할 수 있습니다. 

sudo dnf versionlock add chromium

이 명령을 내리면, 현재 설치된 chromium 버전으로 lock 됩니다. 

dnf의 versionlock 으로 패키지 버전을 고정시킨 예

스샷을 보면, chromium 패키지가 현재 사용 중인 138.0.7204.100 으로 lock 된 것을 확인할 수 있습니다.  verlosionlock 의 목록은 list 명령으로 확인할 수 있습니다. 

sudo dnf versionlock list

스샷을 보면, 2025-07-20일 17:45분에 chromium 패키지가 138.0.7204.100-1 버전으로 lock 되어 있는 것을 알 수 있습니다.  이렇게 versionlock 이 걸린 패키지는 sudo dnf update 명령을 내렸을 때, --excludes 옵션을 사용했을 떄와 동일하게 skip 목록으로 분리 되게 됩니다. 

나중에 해제를 하고 싶다면 

sudo dnf versionlock delete chromium

처럼, delete 명령을 내리면 됩니다. 

 

패키지 설치 기록 확인 : sudo  dnf  list --installed

경우에 따라, 설치된 패키지 목록을 확인할 필요가 있을 수 있는데, 이 때는 list-installed 명령을 사용하면 됩니다. 

sudo dnf list --installed

이 명령을 내리면 현제 설치된 모든 패키지 정보를 볼 수 있습니다.  

 

사용자가 설치한 패키지 목록 확인 : sudo dnf repoquery --userinstalled

sudo dnf list --installed 는 사용자가 설치한 패키지와 의존성 때문에 설치된 패키지들 까치 포함하여 설치된 모든 패키지의 목록을 확인할 수 있습니다. 반면, repoquery 명령을 사용하면 사용자가 설치한 패키지 목록만 확인할 수 있습니다. 이 sub command도 versionlock 과 마찬가지로 dnf-plugins-core를 설치해야 사용할 수 있습니다. 

이 명령이 갖는 의미는 의존성이 배제된 사용자가 설치한 패키지 목록을 얻을 수 있다는 것으로, 이 목록을 이용하여 추후 다른 컴퓨터에 동일한 상태의 구성을 하거나 혹은 현재 사용하는 컴퓨터가 사용 불능 상태가 되어 다시 설치를 해야 할 경우 등에 요긴하게 사용될 수 있다는 것입니다. 

 

설치 히스토리 확인 : sudo  dnf  history

dnf 는 처음 컴퓨터에 linux를 설치했을 때부터 현재까지의 모든 패키지 관련 기록을 모두 갖고 있습니다.  이는  history 서브 커멘드를 통해 확인할 수 있습니다. 

sudo dnf dnf history list

sudo dnf history list 명령이 결과

 

가장 최근에 수행한 작업부터 표시를 해 주는데, 스샷에서 볼 수 있듯이 ID 번호, Command, 해당 명령을 수행하나 날짜, 그리고 그로 인해 변경된 package의 수를 표시해 줍니다.  각각의 작업을 Transaction(트렌젝션) 이라고 부릅니다. 

가장 마지막에 처리한 트렌젝션에 대한 정보를 확인하려면 아래와 같이 sudo dnf history info 명령을 사용하면 됩니다. 

sudo dnf history info

스샷에서 볼 수 있듯이, 언제 누가 어떤 package들을 설치, 제거, 업데이트했는지를 확인할 수 있습니다.  

sudo dnf history info <ID>

sudo dnf history list 에서 확인한 특정 ID의 내용도 확인 가능 합니다. 

sudo dnf history undo <ID>

undo 명령을 사용하면 해당 ID의 트렌젝션을 되돌립니다. 즉, 해당 트렌젝션에서 설치한 패키지는 제거하고, 제거한 패키지는 다시 설치합니다.  업데이트한 패키지는 반대로 다운그레이드됩니다. 

sudo dnf history redo <ID>

 redo는 ID에 해당하는 트렌젝션을 다시 수행합니다. undo와 마찬가지로 설치한 패키지는 설치를 제거한 패키지는 제거, 업그레이드한 패키지는 역시 동일하게 업그레이드합니다. 

sudo dnf history rollback <ID>

rollback 은 ID 트렌젝션 "직전"의 상태로 시스템을 되돌립니다. 즉, ID 트랜젝션부터 현재까지 수행된 모든 DNF 작업들을 모두 최소하고 ID 트랜젝션이 완료된 직후로 시스템을 되돌립니다. 

 

저장소 관리

이번 포스트의 마지막 주제입니다. dnf 저장소 관리는 어떻게 하는지 살펴봅니다. 

우선, 저장소의 목록을 확인은 repolist 명령을 사용합니다. 

sudo dnf repolist

sudo dnf repolist 수행 결과

--all 옵션을 추가하여 sudo dnf repolist --all 을 명령하면, 비활성화된 repo까지 모두 확인할 수 있습니다. 

저장소 정보는 /etc/yum.repo.d 폴더에서 관리됩니다. 

특정 repository를 활성화 혹은 비활성화하고 싶다면 해당 폴더의 해당 repo 파일을 직접 수정하면 됩니다. 

파일을 root 권한 editor로 열고 보면, 맨 아래에 enabled=1 이라고 되어 있는데, 이 값을 0 으로 바꾸면 disable 시킬 수 있습니다. 아예 reporitory를 제거하고 싶다면 해당 파일 자체를 삭제하면 됩니다만, 삭제할 경우 업데이트, 의존성 문제 등 혼란을 야기할 수 있는 만큼, 특별한 문제가 없다면 그냥 놔두는 것이 좋습니다. 

- - - - -

글을 쓰다 보니, 생각보다 꽤 긴 글이 되었네요.
서두에서도 말했듯이, Linux를 처음 설치하고 사용하는 유저 입장에서는 프로그램을 어떻게 설치하고 관리해야 하는지 방법을 익히는 것은 매우 중요하고 필수적인 것입니다. 물론, Fedora Linux를 사용하다고 가정했을 때, package manager는 DNF 만 있는 것은 아닙니다. Flatpak, Snap, AppImage 등등이 있으며, 직접 소스코드를 빌드해서 설치할 수도 있습니다. npm, go, cargo, pip 등 특정 언어에 종속된 것들까지 매우 다양하죠.. 이런 것들은 Linux를 사용해 가면서 자연스럽게 필요에 의해서 익히고 배우며 사용하게 될 것입니다. 하지만, DNF는 Red Hat 계열의 기본 package manager로써 반드시 사용할 줄 알아야 하는 것이니 만큼 사용법을 충분히 익히는 것이 중요 합니다.