Amri za dnf kwa watumiaji wa apt kwenye Rocky na Fedora

Jibu fupi

Kuhama kutoka apt kwenda dnf kimsingi ni mabadiliko ya msamiati. apt install nginx inakuwa dnf install nginx. apt remove nginx inakuwa dnf remove nginx. apt update haina mbadala wa moja kwa moja, kwa sababu dnf hujisasisha metadata ya hazina zake (repository) yenyewe nakala iliyohifadhiwa inapopitwa na wakati. Nusu rahisi ya tafsiri hii inachukua skrini moja. Nusu yenye manufaa ni operesheni nne ambazo hazina mlinganyo wowote: kuongeza hazina, kutendua miamala (transaction), kusakinisha kundi la vifurushi, na kuendesha masasisho yasiyohitaji usimamizi (unattended updates).

Kila amri hapa chini imeandikwa ili uweze kuiendesha kwenye seva yako mwenyewe. Soma muhtasari wa miamala ambao dnf huchapisha kabla ya kujibu y, hasa wakati wa kuondoa vifurushi.

Ni distros zipi hutumia dnf, na zipi hutumia apt

dnf ndiyo meneja wa vifurushi kwenye Fedora, kwenye Red Hat Enterprise Linux (RHEL), na kwenye matoleo yanayojengwa upya kutoka RHEL: Rocky Linux, AlmaLinux na CentOS Stream. apt ndiyo meneja wa vifurushi kwenye Debian na kwenye kila mfumo unaotokana na Debian, ambao kwenye VPS karibu kila mara unamaanisha Ubuntu. Hakuna jibu la tatu. Ikiwa orodha ya picha za mfumo wa mtoa huduma wako inatoa Rocky Linux au AlmaLinux, unapata dnf. Ikiwa inatoa Ubuntu, unapata apt.

Muundo wa kifurushi hufuata zana inayotumika. dnf husakinisha faili za .rpm na hifadhidata yake ni rpm. apt husakinisha faili za .deb na hifadhidata yake ni dpkg. Ndiyo maana kurasa nyingi za usakinishaji za wachuuzi zina kichupo kimoja kwa kila familia, na kwa nini .deb iliyopakuliwa kutoka kwenye ukurasa wa releases wa mradi haina faida kwenye Rocky Linux.

Bila kujali familia unayochagua, kuingia kwa mara ya kwanza kunahitaji kazi ile ile. Dakika kumi za kwanza kwenye VPS mpya inatumika kwa zote mbili. Amri ya usakinishaji pekee ndiyo inayobadilika.

Kila amri ya apt na inayolingana nayo katika dnf

Sakinisha, ondoa, tafuta na onyesha. Hizi hutumia maneno yanayofanana karibu kabisa pande zote mbili.

# 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

apt show ni dnf info. Hilo ndilo kitenzi pekee kilichobadilishwa jina katika kundi hili, lakini tabia moja hutofautiana na huwakanganya watu. dnf remove pia huondoa vitegemezi (dependencies) ambavyo hakuna kingine kinachovihitaji, wakati apt remove huviacha vikiwa vimesakinishwa kwa ajili ya apt autoremove ya baadaye. Kwa hiyo, kuondoa shirika dogo moja kwenye Rocky Linux kunaweza kupendekeza kuondoa maktaba kadhaa pamoja nalo. Soma orodha kabla ya kuthibitisha.

Onyesha upya metadata, angalia nini kinasubiri, na ufanye 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

apt update ni lazima upande wa apt, kwa sababu apt hutumia metadata yoyote iliyopo kwenye diski na itasakinisha kwa furaha toleo ambalo liliondoka kwenye archive miezi iliyopita. dnf huangalia umri wa cache yake kabla ya kila muamala na kupakua metadata mpya yenyewe, kwa hivyo sudo dnf makecache ni kwa ajili ya kulazimisha upakuaji huo ufanyike sasa badala ya wakati wa usakinishaji wako unaofuata.

apt hugawanya upgrade ya mfumo mzima katika sehemu mbili, na dnf haifanyi hivyo. apt upgrade hukataa kuondoa kifurushi chochote kilichosakinishwa, kwa hivyo husimama wakati wowote update inapohitaji kifurushi kiondolewe. apt full-upgrade ndilo toleo linaloruhusiwa kuondoa. dnf haina kizuizi hicho, ambayo inamaanisha dnf upgrade ni sawa na apt full-upgrade, si apt upgrade. dnf update ni jina mbadala la zamani kwa amri hiyo hiyo na bado hufanya kazi.

Maelezo moja ni muhimu ikiwa unaandika script hii: dnf check-update hutoka na status 100 wakati updates zinasubiri na 0 wakati hakuna. apt list --upgradable hutoka na 0 kwa vyovyote vile, kwa hivyo scripts lazima zichambue matokeo yake.

Orodhesha kilichosakinishwa, na ujue ni kifurushi kipi kinachomiliki faili.

# 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

Mstari wa mwisho wa kila kizuizi hujibu swali tofauti na yale yaliyo hapo juu. dpkg -S na rpm -qf hutafuta tu vifurushi ambavyo tayari vimesakinishwa, kwa hivyo hujibu "ni nini kiliweka faili hii hapa". apt-file search na dnf provides hutafuta kwenye repositories, kwa hivyo hujibu "ningesakinisha nini ili kupata faili hii". apt-file ni kifurushi tofauti kwenye Ubuntu na kinahitaji sudo apt-file update kabla ya kuanza kwake kwa mara ya kwanza. dnf provides haihitaji chochote cha ziada, ingawa kuanza kwa mara ya kwanza kunaweza kuwa polepole kwa sababu dnf hupakua orodha za faili za repository ili kujibu.

Ili kuorodhesha faili ndani ya kifurushi ambacho hujasakinisha bado, tumia dnf repoquery -l nginx. Upande wa apt hiyo ni apt-file list nginx.

Autoremove, safisha cache, zuia toleo (hold).

# 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

versionlock haijasakinishwa kwa chaguo-msingi kwenye Rocky Linux au AlmaLinux, kwa hivyo mstari wa kwanza wa hizo hushindwa na No such command: versionlock kwenye mashine mpya. Isakinishe kwanza na sudo dnf install python3-dnf-plugin-versionlock. apt haihitaji chochote cha ziada kwa apt-mark hold, kwa sababu hold ni hali ya dpkg badala ya kuwa plugin.

Mahali ambapo ramani inakwama: kuongeza hazina (repository)

Hii ndiyo sehemu inayowafanya wasimamizi wa Ubuntu kutafuta amri isiyokuwepo. Hakuna add-apt-repository kwenye dnf, na hakuna Personal Package Archives (PPAs). PPA ni huduma inayoendeshwa na Launchpad, na Launchpad ni miundombinu ya Ubuntu. Hakuna kitu katika ulimwengu wa RPM kinachohifadhi kitu kama hicho.

Badala yake, dnf ina faili moja ya maandishi ya kawaida kwa kila hazina ndani ya /etc/yum.repos.d/, inayomalizia na .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

$releasever na $basearch ni vigezo (variables) vya dnf. dnf hujaza namba ya toleo lako kuu na usanifu wa CPU yako wakati wa utekelezaji (runtime), kwa hivyo faili moja hufanya kazi kwenye toleo la 9 na toleo la 10, na kwenye x86_64 na aarch64.

Wauzaji wengi huchapisha faili hiyo na kukuambia uipakue. Maelekezo ya Docker yenyewe kwa ajili ya RHEL na mifumo inayojengwa upya kutoka kwayo ni amri mbili:

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

Mstari wa kwanza upo kwa sababu config-manager ni programu jalizi (plugin), si sehemu ya dnf yenyewe. Ukiuruka, mstari wa pili utafeli kwa kutoa No such command: config-manager. Hakuna kinachokuzuia kupakua faili hiyo hiyo ya .repo kwa kutumia curl ndani ya /etc/yum.repos.d/ kwa mikono, na matokeo yatakuwa sawa. Kusakinisha Docker kwenye VPS inaelezea upande wa Debian wa kazi hiyo hiyo, ambapo hatua inayolingana huandika orodha ya vyanzo (source list) na ufunguo wa kusaini (signing key) katika saraka mbili tofauti.

Tofauti ya mpangilio ndiyo huamua mahali unapoangalia wakati hazina inapoleta hitilafu. apt huweka ufafanuzi ndani ya /etc/apt/sources.list na /etc/apt/sources.list.d/, huku funguo za kusaini zikihifadhiwa kando chini ya /etc/apt/keyrings/. dnf huweka kila kitu ndani ya /etc/yum.repos.d/, na ufunguo ni URL iliyo ndani ya faili ya .repo, kwa hivyo kuna faili moja tu ya kusoma na faili moja ya kufuta. apt ya kisasa imeanza kuelekea kwenye umbo hilo hilo kwa kutumia fomati ya deb822, faili moja ya .sources kwa kila hazina. Ikiwa umekutana na hitilafu ya vyanzo rudufu vya deb822 kwenye Ubuntu, tayari umeshakutana na nusu ya tatizo hili kwa upande wa apt.

EPEL ndicho hifadhi (archive) inayodhaniwa na miongozo mingi

Extra Packages for Enterprise Linux (EPEL) ni mradi wa Fedora unaotengeneza vifurushi (packages) vya Fedora kwa ajili ya RHEL na mifumo inayotokana nayo. Hiki ndicho kitu kinachokaribia zaidi kuwa PPA ya ulimwengu wote, na idadi kubwa ya mafunzo hudhani kuwa tayari imewezeshwa. Ikiwa dnf install inajibu No match for argument kwa kifurushi unachoweza kukiona kwenye tovuti ya mradi huo, EPEL ndicho kitu cha kwanza kukikagua.

Kwenye Rocky Linux na AlmaLinux:

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

CRB ni CodeReady Builder, hifadhi ya maktaba (libraries) inayokuja na usambazaji huu lakini haijawezeshwa kwa chaguo-msingi. Vifurushi vingi vya EPEL hutegemea kitu kilichomo ndani yake, kwa hivyo kuwezesha EPEL bila CRB hakufeli wakati huo. Hufeli baadaye, wakati wa kusakinisha, kwa sababu ya utegemezi (dependencies) ambao haujatatuliwa kwenye kifurushi ambacho hujawahi kukisikia. Washa CRB kwanza na aina hiyo ya hitilafu itatoweka.

Kwenye RHEL yenyewe, CRB hupatikana kupitia usajili wako badala ya kupitia config-manager, kwa hivyo fuata maelekezo ya EPEL ya Red Hat kwa hatua hiyo. Fedora haihitaji yote haya, kwa sababu hifadhi yake kuu tayari ina vitu ambavyo EPEL huleta kutoka matoleo mapya (backports). Sera ya EPEL ni kutochukua nafasi ya kifurushi chochote ambacho RHEL inasambaza, kwa hivyo kuongeza hifadhi hii hakubadilishi chochote kilichosakinishwa tayari kwenye seva yako.

dnf history undo, kitu ambacho apt hakiwezi kufanya

dnf hurekodi kila muamala, na inaweza kutengeneza kinyume chake.

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

dnf history huchapisha orodha yenye namba ya miamala pamoja na mstari wa amri uliyoanzisha kila moja. undo hujenga muamala kinyume: vifurushi vilivyosakinishwa na muamala huo huondolewa, na vifurushi vilivyopandishwa daraja (upgrade) hurudi kwenye toleo ulilokuwa nalo. Hii ndiyo kipengele ambacho watumiaji wa apt hukikosa zaidi baada ya kuhama.

Ina mipaka halisi, na ni vyema kuijua kabla ya kuitegemea. undo inaweza kusakinisha upya toleo la kifurushi ambalo bado lipo katika hazina (repository) iliyowezeshwa, kwa hivyo mara tu toleo la zamani linapoondolewa kwenye mirror, undo inashindwa na kutoa hitilafu ya not-found. Rollback pia huishia kwenye hifadhidata ya vifurushi. Faili ya usanidi iliyoandikwa upya wakati wa upgrade hubaki ikiwa imeandikwa upya, na schema ya hifadhidata ambayo huduma ilihamia wakati wa kuanza kwa mara ya kwanza hubaki ikiwa imehama. dnf hurudisha faili mahali pake. Hairudishi data yako.

apt haina mbadala. /var/log/apt/history.log hurekodi hasa kile kilichotokea, ikijumuisha mstari wa amri, lakini kusoma log si sawa na kuifuta. Urejeshaji kwa upande wa apt ni wa mikono: endesha apt list -a nginx ili kuona ni matoleo yapi ambayo archive bado inayo, kisha sudo apt install nginx=<exact version string> ili kubandika (pin) moja, na ongeza sudo apt-mark hold nginx ili upgrade inayofuata isifute marekebisho yako.

Vikundi vya vifurushi havina sawa na apt

dnf inaweza kusakinisha seti ya vifurushi vilivyopewa jina kwa amri moja.

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

Miongozo ya zamani huandika dnf groupinstall "Development Tools". Alias hiyo hufanya kazi kwenye dnf 4 na imeondolewa kwenye dnf 5, kwa hivyo maneno mawili dnf group install ndiyo tahajia pekee inayofanya kazi kila mahali. Itumie na uache kuifikiria.

apt haina vikundi. Wazo la karibu zaidi la Debian ni metapackage, kifurushi ambacho kimsingi ni kitupu na maudhui yake pekee ni orodha ya utegemezi (dependencies), kama vile build-essential. Tofauti ya kivitendo iko kwenye njia ya kuondoa: kuondoa metapackage huacha utegemezi wake ukiwa umesakinishwa hadi utakapokimbiza apt autoremove, wakati dnf group remove huondoa vifurushi vya kikundi pamoja nayo katika muamala mmoja.

unattended-upgrades na dnf-automatic

Familia zote mbili hutoa njia ya kusakinisha masasisho bila mtumiaji yeyote kuingia kwenye mfumo. Zana hizi hazishiriki chochote isipokuwa lengo lake.

Kwenye Ubuntu na Debian, kifurushi hicho ni unattended-upgrades, ambacho husanidiwa katika /etc/apt/apt.conf.d/50unattended-upgrades, ambapo unaorodhesha asili (origins) ambazo inaruhusiwa kuvuta masasisho kutoka kwake. Kusanidi unattended upgrades kwenye Ubuntu inaelezea faili hilo la usanidi na swali la kuanzisha upya (reboot) mfumo linaloambatana nalo.

Kwenye Rocky Linux, AlmaLinux na Fedora, kifurushi hicho ni dnf-automatic, na timer ya systemd unayoiwasha ndiyo huamua tabia ya mfumo.

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

dnf-automatic-install.timer hupakua na kutumia masasisho. dnf-automatic-download.timer hupakua masasisho na kusimama, ikikuachia wewe jukumu la kusakinisha. dnf-automatic-notifyonly.timer hutoa ripoti pekee. Kila moja ya vitengo hivyo hubatilisha mpangilio wa apply_updates katika /etc/dnf/automatic.conf, kwa hivyo timer unayochagua ni muhimu zaidi kuliko kile ambacho faili la usanidi linasema.

Ili kuzuia masasisho yawe ya marekebisho ya usalama pekee, weka upgrade_type = security katika /etc/dnf/automatic.conf. Kichujio hicho hutegemea hazina (repositories) zako kuchapisha errata za usalama, kwa hivyo hakikisha kwanza kwa kutumia dnf updateinfo list security. Matokeo yasiyo na kitu kwenye seva ambayo ina masasisho yanayosubiri inamaanisha kuwa metadata haipo, na security haitasakinisha chochote.

Kwenye Fedora, dnf 5 imebadilisha jina la kitengo hicho. Sasa ni dnf5-automatic.timer, na inasoma faili lilelile la /etc/dnf/automatic.conf.

Je, yum bado ni amri halali?

Ndiyo, na haifanyi kazi yoyote yenyewe. Kwenye Rocky Linux, AlmaLinux na CentOS Stream, /usr/bin/yum ni symbolic link inayoelekeza kwenye dnf. Hakiki yako:

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

Syntax ya zamani ya yum inaendelea kujitokeza kwenye mafunzo kwa sababu nyingi zake bado hufanya kazi moja kwa moja. yum install, yum remove na yum update zote hufanya kazi. Kuna tabia moja inayofaa kuachwa: yum-config-manager bado ipo kama binary yake yenyewe kwenye mifumo ya dnf 4, lakini dnf config-manager ndiyo tahajia inayotumiwa na nyaraka za sasa, na ndiyo inayozidi kufanya kazi seva inapohamia kwenye dnf 5.

dnf 4 na dnf 5: hakiki kabla ya kunakili amri

dnf 5 ni toleo lililoandikwa upya, na limebadilisha tahajia ya amri kadhaa. Fedora 41 na matoleo ya baadaye yanatumia dnf. Matoleo ya biashara (enterprise rebuilds) yamekuwa yakichelewa kubadili, kwa hivyo usikisie kulingana na jina la usambazaji. Tekeleza dnf --version kwenye seva yako na usome mstari wa kwanza, kwa sababu namba hiyo ndiyo huamua sintaksia unayohitaji hapa chini.

Mfano dhahiri unatoka kwa Docker, ambayo huchapisha amri tofauti ya repository kwa kila toleo. Kwenye RHEL na matoleo yake yanayofanana, ukitumia dnf 4:

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

Kwenye Fedora, ukitumia dnf 5:

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

Muuzaji yuleyule, kazi ileile, maneno tofauti. dnf 5 ilibadilisha config-manager kuwa zana inayotumia subcommands, kwa hivyo flag ya zamani ya --add-repo haikubaliki na utapata kosa la matumizi (usage error) badala ya repository. Amri nyingine utakayokutana nayo ni kuwezesha repository: dnf config-manager --set-enabled crb kwenye dnf 4 inakuwa dnf config-manager setopt crb.enabled=1 kwenye dnf 5.

Uamuzi unaozingatia uhalisia

Kuchagua usambazaji wa seva kwa kutegemea tu kiongozi wa vifurushi (package manager) ni kigezo kisicho sahihi. dnf na apt hufanya kazi sawa, na msamiati wake hujifunzika ndani ya mchana mmoja. Kinachobadilisha mwaka wako ni mfano wa utoaji (release model) uliopo nyuma ya hazina (repository). Fedora husonga haraka na toleo fulani huacha kupata masasisho takriban miezi kumi na tatu baada ya kutoka, jambo ambalo ni sawa kwa workstation lakini ni kero kwa seva ambayo hutaki kuijenga upya. Rocky Linux na AlmaLinux hufuata RHEL, hivyo unapata muda wa usaidizi wa miaka kumi na matoleo ya vifurushi yanayobaki vilevile kwa makusudi. Ubuntu hutoa maumbo yote mawili, na tofauti kati ya Ubuntu LTS na matoleo ya muda kwenye seva ni uamuzi uleule unaofanywa ndani ya ulimwengu wa apt.

Kufikia Agosti 2026, haya yote ni picha za kawaida za VPS. Chagua muda wa usaidizi unaotaka, kisha jifunze amri kumi zilizotajwa hapo juu.

FAQ

Ni amri gani ya dnf inayolingana na apt update?

Hakuna amri unayopaswa kuendesha. dnf hukagua umri wa metadata yake iliyohifadhiwa (cache) kabla ya kila shughuli na kupakua nakala mpya ikiwa imepitwa na wakati, kwa hivyo dnf install kwenye seva ambayo hujaitumia kwa mwezi mmoja bado itaona vifurushi vya sasa. sudo dnf makecache ipo na inalazimisha upakuaji huo, lakini matumizi yake halisi ni kuhamisha muda wa kusubiri hadi wakati unaochagua badala ya kuingia kwenye usakinishaji wako unaofuata. Amri inayojibu "ni nini kinanisubiri" ni dnf check-update, ambayo inalingana na apt list --upgradable na hutoka na status 100 wakati masasisho yanapopatikana.

Je, kuna kitu kinacholingana na PPA kwenye Rocky Linux au Fedora?

Hapana. Personal package archives ni huduma ya Launchpad na Launchpad ni miundombinu ya Ubuntu, kwa hivyo add-apt-repository haina kitu cha kutafsiriwa. Kitu kinacholingana katika RPM ni faili la .repo ndani ya /etc/yum.repos.d/ lililo na jina, baseurl na gpgkey. Wauzaji huchapisha faili hilo kwa ajili yako, na sudo dnf config-manager --add-repo <url> kwenye dnf 4, au sudo dnf config-manager addrepo --from-repofile <url> kwenye dnf 5, hulipakua na kuliweka mahali pake. Kwa programu za ziada kwa ujumla, jibu mara nyingi ni EPEL, ambayo unaiwasha kwa sudo dnf config-manager --set-enabled crb ikifuatiwa na sudo dnf install epel-release.

Je, ninaweza kutengua dnf upgrade iliyoharibu seva yangu?

Ndiyo, ndani ya mipaka fulani. Endesha sudo dnf history ili kupata namba ya shughuli, sudo dnf history info <id> ili kuona hasa kile kilichobadilika, kisha sudo dnf history undo <id>. Utenguzi hushindwa ikiwa toleo la zamani la kifurushi halipo tena katika hazina (repository) yoyote iliyowashwa, kwa sababu dnf haina cha kusakinisha tena. Pia, inatengua mabadiliko ya vifurushi pekee. Faili la usanidi lililoandikwa upya na sasisho, au database iliyohamishwa na huduma wakati wa kuanza mara ya kwanza, hubaki kama ilivyo. apt haina amri yoyote inayolingana na hii, ina rekodi tu katika /var/log/apt/history.log.

Je, yum bado inafanya kazi kwenye Rocky Linux na AlmaLinux?

Inafanya kazi kwa sababu /usr/bin/yum ni symbolic link ya dnf. Ithibitishe kwenye mashine yako kwa ls -l /usr/bin/yum. Kuandika yum install httpd huendesha dnf, kwa hivyo mafunzo ya zamani mengi bado yanafanya kazi. Andika hati (scripts) na nyaraka mpya kwa kutumia dnf, kwa kuwa jina la yum ni kwa ajili ya utangamano pekee, na pendelea dnf config-manager badala ya binary ya zamani ya yum-config-manager.

Kwa nini dnf remove inataka kufuta vifurushi vingi sana?

Kwa sababu dnf huondoa dependencies ambazo hakuna kitu kingine kinachozihitaji kama sehemu ya shughuli hiyo hiyo, wakati apt remove huviacha vikiwa vimesakinishwa hadi uendeshe apt autoremove kando. Kwa hivyo, uondoaji unaoonekana kuwa mdogo kwenye Ubuntu unaweza kuchapisha orodha ndefu kwenye Rocky Linux. Orodha hiyo mara nyingi ni sahihi, lakini isome kabla ya kuthibitisha. Ikiwa kifurushi kilichomo kwenye orodha hiyo ni kile unachotaka kukihifadhi, kisakinishe waziwazi kwanza ili dnf ikirekodi kama kinachohitajika kwa haki yake yenyewe.