How dnf Differs From apt

한국어 원문으로 표시합니다.

한 줄 요약

dnf 의 결정적 차이는 모든 설치가 트랜잭션으로 기록되고 되돌릴 수 있다는 것이다. apt 에는 이에 대응하는 기능이 없다.

Concept map: 모든 설치가 트랜잭션으로 기록되고 되돌릴 수 있다 · 기록 · 되돌리는 명령 · 다만 한계가 명확하다.

왜 이게 필요했나

우분투에서 넘어온 사람이 처음 놀라는 지점이 이것이다.

dnf history                    # 지금까지의 모든 트랜잭션 목록
dnf history info 42            # 42번 트랜잭션에서 무엇이 바뀌었나
dnf history undo 42            # 42번을 되돌린다
dnf history rollback 41        # 41번 시점의 상태로 되돌린다

apt 에는 /var/log/apt/history.log 라는 기록은 있지만 되돌리는 명령은 없다. 이 차이가 운영 방식을 바꾼다. RHEL 계열에서는 "일단 설치해 보고 아니면 되돌린다" 가 가능하다.

다만 한계가 명확하다. 이전 버전 패키지가 저장소에 없으면 다운그레이드가 실패한다. 그리고 Red Hat 은 시스템 패키지(selinux, selinux-policy, kernel, glibc 및 glibc 에 의존하는 gcc 등)의 다운그레이드를 지원하지 않는다고 명시한다. 롤백은 만능이 아니다.

어떻게 동작하나

명령 대응표

작업	apt	dnf
색인 갱신	`apt-get update`	(자동, 필요시 `dnf makecache`)
설치	`apt-get install X`	`dnf install X`
제거	`apt-get remove X`	`dnf remove X`
검색	`apt-cache search X`	`dnf search X`
정보	`apt-cache show X`	`dnf info X`
파일→패키지	`dpkg -S /path`	`dnf provides /path` (미설치 포함)
설치된 파일 목록	`dpkg -L X`	`rpm -ql X`
업그레이드	`apt-get upgrade`	`dnf upgrade`
버전 고정	`apt-mark hold`	`dnf versionlock add`
롤백	없음	`dnf history undo`

dnf provides 가 특히 강력하다. apt 의 dpkg -S 는 이미 설치된 파일만 찾지만, dnf provides 는 저장소 메타데이터를 뒤져 아직 설치되지 않은 패키지까지 찾아 준다.

dnf provides '*/nginx.conf'
dnf provides 'libnl-3.so.200()(64bit)'

두 번째 예시가 중요하다. RPM 에서 의존성의 단위는 패키지 이름이 아니라 능력(capability) 이다. 공유 라이브러리의 소네임, 파일 경로, 심지어 심볼 버전까지 의존 대상이 될 수 있다.

dnf repoquery --requires httpd
dnf repoquery --requires --resolve --recursive httpd | sort -u | wc -l

--requires 는 요구하는 능력, --resolve 는 그 능력을 제공하는 패키지로 치환, --recursive 는 재귀적으로 계속 내려간다. 폐쇄망 반입 목록을 만들 때 핵심 도구다.

저장소 파일

# /etc/yum.repos.d/labhub-local.repo
[labhub-local]
name=LabHub local (snapshot 2026-08-20)
baseurl=file:///srv/repo/labhub
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-labhub
metadata_expire=-1

각 키의 기본값을 알아 두는 것이 중요하다.

enabled 기본 True
gpgcheck 기본 False — 명시적으로 켜야 한다
repo_gpgcheck(메타데이터 서명 검증) 기본 False
priority 기본 99
metadata_expire 기본 48시간. 폐쇄망 로컬 저장소에서는 -1(만료 없음)로 두는 편이 낫다
module_hotfixes 기본 False

저장소 표시 이름에 스냅샷 날짜를 박아 두면 6개월 뒤 dnf repolist -v 한 줄로 그 서버가 언제 시점 콘텐츠로 설치됐는지 알 수 있다.

캐시

폐쇄망에서 가장 많은 신고가 "저장소에 패키지를 넣었는데 안 보인다" 다. 원인은 둘 중 하나다.

# 저장소 쪽: 메타데이터를 다시 만들었는가 (이걸 빼먹는 경우가 정말 많다)
createrepo_c --update /srv/repo/labhub
# 클라이언트 쪽: 캐시를 만료 표시 (가장 가벼움)
dnf clean expire-cache
# 그래도 안 되면
dnf clean metadata
# 최후의 수단
dnf clean all
dnf makecache

각각의 정의: expire-cache 는 메타데이터를 만료 표시만, metadata 는 메타데이터 제거, packages 는 캐시된 패키지 제거, all 은 전부.

현장에서 만나는 모습

dnf update --security 가 조용히 "할 일 없음" 으로 끝나는 경우. 보안 권고(updateinfo) 메타데이터가 저장소에 없으면 그렇게 된다. createrepo_c 는 rpm 파일에서 primary/filelists/other 만 만들 수 있고, 권고 정보는 rpm 안에 없다. 조용히 아무것도 하지 않는다는 점이 위험하다. dnf updateinfo --summary 로 확인하는 습관이 필요하다.

다음 실습에서 할 것

dnf 로 저장소를 확인하고, 설치하고, provides 로 역추적하고, 히스토리로 롤백하고, 버전을 고정한다.