apt to dnf: command equivalents para sa Rocky at Fedora

Ang maikling sagot

Ang paglipat mula sa apt patungong dnf ay isa lamang pagbabago sa bokabularyo. Ang apt install nginx ay nagiging dnf install nginx. Ang apt remove nginx ay nagiging dnf remove nginx. Ang apt update ay walang direktang katumbas, dahil kusa nang nire-refresh ng dnf ang repository metadata nito kapag luma na ang naka-cache na kopya. Ang madaling bahagi ng pagsasalin ay kayang ipakita sa isang screen. Ang kapaki-pakinabang na bahagi ay ang apat na operasyon na walang katapat na command: pagdaragdag ng repository, pag-undo ng transaction, pag-install ng package group, at pagpapatakbo ng unattended updates.

Ang bawat command sa ibaba ay nakasulat para patakbuhin mo sa sarili mong server. Basahin ang transaction summary na ipinapakita ng dnf bago ka sumagot ng y, lalo na sa mga pag-aalis (removals) ng package.

Aling mga distro ang gumagamit ng dnf, at alin ang gumagamit ng apt

Ang dnf ang package manager sa Fedora, sa Red Hat Enterprise Linux (RHEL), at sa mga rebuild ng RHEL: Rocky Linux, AlmaLinux, at CentOS Stream. Ang apt naman ang package manager sa Debian at sa lahat ng nakabase sa Debian, na sa konteksto ng VPS ay halos laging nangangahulugang Ubuntu. Wala nang ibang sagot. Kung ang listahan ng image ng iyong provider ay nag-aalok ng Rocky Linux o AlmaLinux, dnf ang makukuha mo. Kung Ubuntu naman ang inaalok, apt ang makukuha mo. Ang dahilan kung bakit ang isang panig ng hatian na ito ay may apat na pangalan para sa halos iisang sistema ay isang kuwentong dapat mong malaman bago ka pumili sa pagitan nila, at ang kung paano naging Fedora, RHEL, CentOS, Rocky at AlmaLinux ang Red Hat Linux ay nagpapaliwanag kung saan nanggaling ang bawat isa.

Ang format ng package ay sumusunod sa tool. Ang dnf ay nag-i-install ng mga .rpm file at ang database nito ay rpm. Ang apt ay nag-i-install ng mga .deb file at ang database nito ay dpkg. Iyan ang dahilan kung bakit maraming pahina ng installation ng vendor ang may magkahiwalay na tab para sa bawat pamilya, at kung bakit ang isang .deb na na-download mula sa release page ng isang proyekto ay walang silbi sa Rocky Linux.

Anuman ang pamilyang mapuntahan mo, ang unang login ay pareho lang ang trabaho. Ang unang sampung minuto sa isang bagong VPS ay applicable sa pareho. Ang install command lang ang nagbabago.

Bawat apt command at ang katumbas nitong dnf

Install, remove, search, at show. Halos magkapareho ang mga salitang ginagamit sa magkabilang panig.

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

Ang apt show ay dnf info. Ito lang ang nag-iisang command na nagbago ang pangalan sa grupo, pero may pagkakaiba sa behavior na madalas makapang-abala sa mga user. Ang dnf remove ay nagtatanggal din ng mga dependency na hindi na kailangan ng ibang package, habang ang apt remove ay hinahayaan lang ang mga ito na manatiling naka-install para sa susunod na apt autoremove. Kaya ang pag-remove ng isang maliit na utility sa Rocky Linux ay maaaring magresulta sa pag-remove ng dose-dosenang library. Basahin muna ang listahan bago mag-confirm.

Refresh metadata, tingnan ang mga pending na update, at mag-upgrade.

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

Ang apt update ay mandatory sa panig ng apt, dahil ginagamit ng apt ang anumang metadata na nasa disk at handa itong mag-install ng bersyon na matagal nang wala sa archive. Ang dnf ay sinusuri ang edad ng cache nito bago ang bawat transaction at kusa itong nagda-download ng bagong metadata, kaya ang sudo dnf makecache ay ginagamit lang para pilitin ang pag-download ngayon sa halip na sa susunod mong pag-install.

Hinahati ng apt ang system upgrade sa dalawa, habang ang dnf ay hindi. Ang apt upgrade ay tumatangging mag-remove ng anumang naka-install na package, kaya humihinto ito kapag ang isang update ay nangangailangan ng pag-remove ng package. Ang apt full-upgrade ang bersyon na pinapayagang mag-remove. Ang dnf ay walang ganitong restriksyon, na nangangahulugang ang dnf upgrade ang katumbas ng apt full-upgrade, hindi ng apt upgrade. Ang dnf update ay isang lumang alias para sa parehong command at gumagana pa rin.

Isang detalye ang mahalaga kung mag-i-script ka nito: ang dnf check-update ay nag-e-exit na may status 100 kapag may mga pending na update at 0 kapag wala. Ang apt list --upgradable ay laging nag-e-exit ng 0, kaya kailangang i-parse ng mga script ang output nito.

I-list ang mga naka-install, at alamin kung aling package ang nagmamay-ari ng isang file.

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

Ang huling linya ng bawat block ay sumasagot sa ibang tanong kumpara sa mga nasa itaas nito. Ang dpkg -S at rpm -qf ay naghahanap lamang sa mga package na naka-install na, kaya sinasagot nito ang "ano ang naglagay ng file na ito rito". Ang apt-file search at dnf provides ay naghahanap sa mga repository, kaya sinasagot nito ang "ano ang dapat kong i-install para makuha ang file na ito". Ang apt-file ay isang hiwalay na package sa Ubuntu at nangangailangan ng sudo apt-file update bago ang unang pagtakbo nito. Ang dnf provides ay walang kailangang extra, bagaman ang unang pagtakbo ay maaaring mabagal dahil nagda-download ang dnf ng mga file list ng repository para makasagot.

Para i-list ang mga file sa loob ng isang package na hindi mo pa na-i-install, gamitin ang dnf repoquery -l nginx. Sa panig ng apt, ito ay apt-file list nginx.

Autoremove, linisin ang cache, at i-hold ang isang bersyon.

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

Ang versionlock ay hindi naka-install bilang default sa Rocky Linux o AlmaLinux, kaya ang una sa mga linyang iyon ay mag-fe-fail na may No such command: versionlock sa isang bagong box. I-install muna ito gamit ang sudo dnf install python3-dnf-plugin-versionlock. Ang apt ay walang kailangang extra para sa apt-mark hold, dahil ang hold ay isang dpkg state at hindi isang plugin.

Kung saan nagkakaroon ng problema sa mapping: pagdagdag ng repository

Ito ang bahagi kung saan naghahanap ang mga Ubuntu admin ng command na hindi naman umiiral. Walang add-apt-repository sa dnf, at walang personal package archives (PPAs). Ang PPA ay isang serbisyong pinapatakbo ng Launchpad, at ang Launchpad ay imprastraktura ng Ubuntu. Walang host para sa ganito sa mundo ng RPM.

Ang kapalit nito sa dnf ay isang plain text file bawat repository sa /etc/yum.repos.d/, na nagtatapos sa .repo.

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

Ang $releasever at $basearch ay mga dnf variable. Pinupunan ng dnf ang iyong major release number at CPU architecture sa runtime, kaya gumagana ang parehong file sa version 9 at version 10, at sa x86_64 at aarch64.

Karamihan sa mga vendor ay naglalathala ng file na iyon at nag-uutos na i-fetch ito. Ang sariling mga instruction ng Docker para sa RHEL at mga rebuild nito ay binubuo ng dalawang command:

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Ang unang linya ay kailangan dahil ang config-manager ay isang plugin, hindi bahagi ng mismong dnf. Laktawan ito at mabibigo ang pangalawang linya dahil sa No such command: config-manager. Walang pipigil sa iyo na i-download ang parehong .repo file gamit ang curl papunta sa /etc/yum.repos.d/ nang manual, at magiging pareho lang ang resulta. Ang Pag-install ng Docker sa isang VPS ay tumatalakay sa panig ng Debian para sa parehong gawain, kung saan ang katumbas na hakbang ay nagsusulat ng source list at signing key sa dalawang magkaibang directory.

Ang pagkakaiba sa layout ang nagtatakda kung saan ka titingin kapag nagkaproblema ang isang repository. Ang apt ay nagtatago ng mga definition sa /etc/apt/sources.list at /etc/apt/sources.list.d/, habang ang mga signing key ay hiwalay na nakalagay sa /etc/apt/keyrings/. Ang dnf ay nagtatago ng lahat sa /etc/yum.repos.d/, at ang key ay isang URL sa loob ng .repo file, kaya isang file lang ang kailangang basahin at isang file lang ang kailangang burahin. Ang mas bagong apt ay lumilipat na rin sa ganitong format gamit ang deb822, kung saan may isang .sources file bawat repository. Kung naranasan mo na ang deb822 duplicate sources error sa Ubuntu, nakaharap mo na ang kalahati ng problemang ito sa apt.

Ang EPEL ang archive na inaasahan ng karamihan sa mga guide

Ang Extra Packages for Enterprise Linux (EPEL) ay isang proyekto ng Fedora na bumubuo ng mga Fedora package para sa RHEL at sa mga rebuild nito. Ito ang pinakamalapit na bagay sa isang universal PPA sa mundong ito, at napakaraming tutorial ang nag-aakalang naka-enable na ito. Kung ang dnf install ay sumasagot ng No match for argument para sa isang package na nakikita mo naman sa website ng mismong proyekto, ang EPEL ang unang dapat suriin.

Sa Rocky Linux at AlmaLinux:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

Ang CRB ay CodeReady Builder, isang repository ng mga library na kasama sa distribution pero hindi naka-enable nang default. Karamihan sa mga EPEL package ay nakadepende sa mga library na nasa loob nito, kaya ang pag-enable sa EPEL nang walang CRB ay hindi magdudulot ng error sa sandaling iyon. Magkakaroon lamang ng error sa oras ng pag-install, kung saan magkakaroon ng unresolved dependencies sa isang package na hindi mo pa naririnig. I-enable muna ang CRB at mawawala ang ganitong uri ng error.

Sa RHEL mismo, ang CRB ay dumarating sa pamamagitan ng iyong subscription sa halip na sa config-manager, kaya sundin ang sariling EPEL instructions ng Red Hat para sa hakbang na iyon. Hindi kailangan ng Fedora ang mga ito dahil ang main repository nito ay dala na ang mga backport na nasa EPEL. Ang polisiya ng EPEL ay huwag palitan ang anumang package na inilalabas ng RHEL, kaya ang pagdagdag sa repository ay hindi makakaapekto sa anumang naka-install na sa iyong server.

dnf history undo, ang bagay na hindi kayang gawin ng apt

Itinatala ng dnf ang bawat transaksyon, at kaya nitong bumuo ng kabaligtaran ng isa sa mga ito.

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

Ang dnf history ay nagpi-print ng may numerong listahan ng mga transaksyon kasama ang command line na nagpasimula sa bawat isa. Ang undo ay bumubuo ng kabaligtarang transaksyon: ang mga package na in-install ng transaksyong iyon ay aalisin, at ang mga package na in-upgrade nito ay ibabalik sa bersyong dati mong gamit. Ito ang feature na pinaka-hinahanap ng mga gumagamit ng apt paglipat nila.

Mayroon itong mga limitasyon, at mahalagang malaman ang mga ito bago ka umasa rito. Ang undo ay kaya lamang mag-reinstall ng bersyon ng package na umiiral pa sa isang enabled na repository, kaya kapag ang lumang build ay inalis na sa mirror, ang undo ay magsasagawa ng not-found error. Humihinto rin ang rollback sa database ng package. Ang config file na binago ng upgrade ay mananatiling binago, at ang database schema na ni-migrate ng isang serbisyo noong unang start ay mananatiling migrate. Ibinabalik ng dnf ang mga file. Hindi nito ibinabalik ang iyong data.

Walang katumbas na feature ang apt. Ang /var/log/apt/history.log ay nagtatala nang eksakto kung ano ang nangyari, kasama ang command line, ngunit ang pagbabasa ng log ay hindi pag-undo nito. Ang recovery sa panig ng apt ay manual: patakbuhin ang apt list -a nginx upang makita kung anong mga bersyon ang hawak pa ng archive, pagkatapos ay sudo apt install nginx=<exact version string> upang i-pin ang isa, at idagdag ang sudo apt-mark hold nginx upang hindi i-undo ng susunod na upgrade ang iyong ginawang ayos.

Walang katumbas na apt ang mga package group

Kayang mag-install ng dnf ng isang nakapangalang set ng mga package sa isang command.

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

Ang mga lumang gabay ay gumagamit ng dnf groupinstall "Development Tools". Gumagana ang alias na iyon sa dnf 4 pero wala na ito sa dnf 5, kaya ang dalawang-salitang dnf group install na lang ang tanging spelling na gumagana kahit saan. Gamitin ito at huwag nang mag-alala pa.

Walang mga group ang apt. Ang pinakamalapit na konsepto sa Debian ay metapackage, isang package na walang laman kundi listahan ng mga dependency, gaya ng build-essential. Ang praktikal na pagkakaiba nito ay unti-unti nang nawawala: ang pag-remove ng metapackage ay nag-iiwan sa mga dependency nito na naka-install hanggang sa patakbuhin mo ang apt autoremove, habang ang dnf group remove ay kasamang tinatanggal ang mga package ng group sa iisang transaction.

unattended-upgrades at dnf-automatic

Ang parehong pamilya ng tools ay may paraan para mag-install ng updates nang walang naka-log in na user. Wala silang pagkakatulad maliban sa layunin.

Sa Ubuntu at Debian, ang package ay unattended-upgrades, na naka-configure sa /etc/apt/apt.conf.d/50unattended-upgrades, kung saan ililista mo ang mga origin na pinapayagang pagkunan ng updates. Ang Pag-set up ng unattended upgrades sa Ubuntu ay tumatalakay sa config file na iyon at sa usapin ng reboot na kasama nito.

Sa Rocky Linux, AlmaLinux, at Fedora, ang package ay dnf-automatic, at ang systemd timer na i-enable mo ang magtatakda ng behavior nito.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

Ang dnf-automatic-install.timer ay nagda-download at nag-a-apply ng updates. Ang dnf-automatic-download.timer ay nagda-download lamang at hihinto, kaya ikaw ang mag-i-install nito. Ang dnf-automatic-notifyonly.timer ay nagre-report lamang. Ang bawat isa sa mga unit na ito ay nag-o-override sa setting na apply_updates sa loob ng /etc/dnf/automatic.conf, kaya mas mahalaga ang timer na pipiliin mo kaysa sa nakasulat sa config file. Ang pag-install ng update ay hindi nagre-restart ng mga program na tumatakbo pa rin gamit ang lumang code, kaya mainam na suriin ang kung alin sa mga update na iyon ang nangangailangan ng reboot at alin ang service restart lamang bago mo ipagpalagay na patched na ang server.

Para limitahan ito sa security fixes lamang, i-set ang upgrade_type = security sa /etc/dnf/automatic.conf. Ang filter na ito ay nakadepende sa pag-publish ng security errata ng iyong mga repository, kaya suriin muna ito gamit ang dnf updateinfo list security. Ang walang resultang output sa isang server na may pending updates ay nangangahulugang wala roon ang metadata, at ang security ay walang mai-install na kahit ano.

Sa Fedora, binago ng dnf 5 ang pangalan ng unit. Ito ay dnf5-automatic.timer, at binabasa nito ang parehong /etc/dnf/automatic.conf.

Ang yum ba ay isa pa ring totoong command?

Oo, at wala itong ginagawa nang mag-isa. Sa Rocky Linux, AlmaLinux, at CentOS Stream, ang /usr/bin/yum ay isang symbolic link na nakaturo sa dnf. I-check ang sa iyo:

ls -l /usr/bin/yum
dnf --version

Ang lumang yum syntax ay patuloy na lumalabas sa mga tutorial dahil karamihan dito ay direktang gumagana pa rin. Ang yum install, yum remove, at yum update ay pawang gumagana. May isang nakasanayan na dapat nang itigil: ang yum-config-manager ay umiiral pa rin bilang sarili nitong binary sa mga dnf 4 system, ngunit ang dnf config-manager ang spelling na ginagamit sa kasalukuyang dokumentasyon, at ito ang mananatiling gumagana kapag ang server ay lumipat na sa dnf 5.

dnf 4 at dnf 5: mag-check bago mag-copy ng command

Ang dnf 5 ay isang rewrite, at binago nito ang spelling ng ilang command. Ang Fedora 41 at mas bago ay mayroon nito bilang dnf. Mas mabagal ang paglipat ng mga enterprise rebuild, kaya huwag manghula base sa pangalan ng distribution. Patakbuhin ang dnf --version sa sarili mong server at basahin ang unang linya, dahil ang numerong iyon ang magtatakda kung aling syntax sa ibaba ang kailangan mo.

Ang pinakamalinaw na halimbawa ay mula sa Docker, na naglalathala ng magkaibang repository command para sa bawat isa. Sa RHEL at mga rebuild nito, gamit ang dnf 4:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Sa Fedora, gamit ang dnf 5:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

Parehong vendor, parehong trabaho, magkaibang salita. Ginawa ng dnf 5 ang config-manager na isang tool na nakabase sa subcommand, kaya hindi tinatanggap ang lumang --add-repo flag at makakatanggap ka ng usage error sa halip na repository. Ang isa pa na makakasalamuha mo ay ang pag-enable ng repository: ang dnf config-manager --set-enabled crb sa dnf 4 ay nagiging dnf config-manager setopt crb.enabled=1 sa dnf 5.

Ang desisyong tunay na mahalaga

Ang pagpili ng server distribution base lamang sa package manager ay maling batayan. Pareho lang ang ginagawa ng dnf at apt, at isang hapon lang ay matututunan mo na ang vocabulary nito. Ang magpapabago sa takbo ng iyong taon ay ang release model sa likod ng repository. Mabilis ang galaw ng Fedora at ang isang release ay humihinto sa pagtanggap ng updates pagkalipas ng humigit-kumulang labintatlong buwan mula nang lumabas ito; ayos ito para sa workstation pero mahirap para sa server na ayaw mong i-rebuild. Ang Rocky Linux at AlmaLinux ay sumusunod sa RHEL, kaya makakakuha ka ng sampung taong support window at mga package version na sadyang hindi nagbabago. Ang Ubuntu ay nag-aalok ng parehong opsyon, at ang pagkakaiba ng Ubuntu LTS at interim releases sa isang server ay ang parehong desisyong ginagawa sa loob ng mundo ng apt.

Simula noong August 2026, ang lahat ng ito ay mga ordinaryong VPS image. Piliin ang support window na gusto mo, pagkatapos ay aralin ang sampung command sa itaas.

FAQ

Ano ang katumbas ng apt update sa dnf?

Walang command na kailangan mong patakbuhin. Bago ang bawat transaction, sinusuri ng dnf kung gaano na katagal ang cached metadata nito at nagda-download ng bago kapag expired na ito, kaya ang dnf install sa isang server na hindi mo ginalaw sa loob ng isang buwan ay makakakita pa rin ng mga kasalukuyang package. Umiiral ang sudo dnf makecache at pinipilit nito ang pag-download, pero ang tunay na gamit nito ay ilipat ang delay sa oras na gusto mo sa halip na sa susunod mong pag-install. Ang command na sumasagot sa "ano ang naghihintay para sa akin" ay dnf check-update, na nagma-map sa apt list --upgradable at nag-e-exit na may status 100 kapag may available na mga update.

May katumbas ba ang PPA sa Rocky Linux o Fedora?

Wala. Ang mga Personal Package Archive ay serbisyo ng Launchpad at ang Launchpad ay imprastraktura ng Ubuntu, kaya walang katumbas ang add-apt-repository. Ang katumbas sa RPM ay isang .repo file sa /etc/yum.repos.d/ na naglalaman ng pangalan, isang baseurl, at isang gpgkey. Inilalathala ng mga vendor ang file na iyon para sa iyo, at ang sudo dnf config-manager --add-repo <url> sa dnf 4, o sudo dnf config-manager addrepo --from-repofile <url> sa dnf 5, ang nagda-download nito sa tamang lugar. Para sa pangkalahatang extra software, ang sagot ay karaniwang EPEL, na ia-enable mo gamit ang sudo dnf config-manager --set-enabled crb na susundan ng sudo dnf install epel-release.

Maaari ko bang i-undo ang dnf upgrade na sumira sa aking server?

Oo, sa loob ng mga limitasyon. Patakbuhin ang sudo dnf history para mahanap ang transaction number, sudo dnf history info <id> para makita nang eksakto ang mga binago nito, pagkatapos ay sudo dnf history undo <id>. Mabibigo ang undo kung ang lumang bersyon ng package ay wala na sa anumang enabled na repository, dahil walang pagmumulan ang dnf para i-reinstall ito. Binabaligtad lang din nito ang mga pagbabago sa package. Ang configuration file na na-rewrite ng upgrade, o database na na-migrate ng isang serbisyo sa unang pag-start, ay mananatili kung ano ito. Ang apt ay walang katumbas na command, kundi ang record lang sa /var/log/apt/history.log.

Gumagana pa ba ang yum sa Rocky Linux at AlmaLinux?

Gumagana ito dahil ang /usr/bin/yum ay isang symbolic link sa dnf. Kumpirmahin ito sa sarili mong box gamit ang ls -l /usr/bin/yum. Ang pag-type ng yum install httpd ay nagpapatakbo ng dnf, kaya ang karamihan sa mga lumang tutorial ay gumagana pa rin. Sumulat ng mga bagong script at dokumentasyon gamit ang dnf, dahil ang pangalang yum ay para sa compatibility lamang, at mas piliin ang dnf config-manager kaysa sa mas lumang yum-config-manager binary.

Bakit gustong burahin ng dnf remove ang napakaraming package?

Dahil tinatanggal ng dnf ang mga dependency na hindi na kailangan ng iba bilang bahagi ng parehong transaction, habang ang apt remove ay hinahayaan lang silang naka-install hanggang sa patakbuhin mo ang apt autoremove nang hiwalay. Kaya ang pag-remove na mukhang maliit sa Ubuntu ay maaaring magpakita ng mahabang listahan sa Rocky Linux. Karaniwang tama ang listahan, pero basahin ito bago kumpirmahin. Kung ang isang package sa listahan ay gusto mong panatilihin, i-install ito nang tahasan (explicitly) muna para ma-record ito ng dnf bilang kailangan.