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 (repository) yenyewe wakati nakala iliyohifadhiwa (cache) inapopitwa na wakati. Nusu rahisi ya tafsiri hii inachukua skrini moja. Nusu ya maana zaidi ni operesheni nne ambazo hazina ramani yoyote: kuongeza hazina, kutengua miamala (transaction), kusakinisha kundi la vifurushi (package group), na kuendesha masasisho yasiyohitaji usimamizi (unattended updates).

Kila amri hapa chini imeandikwa ili uweze kuiendesha kwenye seva yako mwenyewe. Soma muhtasari wa muamala ambao dnf huchapisha kabla ya kujibu y, hasa wakati wa kufuta 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 ya 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 seva ya mtoa huduma wako inatoa Rocky Linux au AlmaLinux, unapata dnf. Ikiwa inatoa Ubuntu, unapata apt. Sababu inayofanya upande mmoja wa mgawanyo huo kuwa na majina manne kwa mfumo ambao kimsingi ni uleule ni hadithi inayofaa kujulikana kabla ya kuchagua kati yao, na jinsi Red Hat Linux ilivyokuwa Fedora, RHEL, CentOS, Rocky na AlmaLinux inaeleza asili ya kila moja.

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 ndiyo maana .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 ileile. Dakika kumi za kwanza kwenye VPS mpya inahusu zote mbili. Amri ya kusakinisha pekee ndiyo inayobadilika.

Kila amri ya apt na mwenzake wa dnf

Sakinisha, ondoa, tafuta na onyesha. Maneno haya yanafanana 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 inatofautiana na huwashtua watu. dnf remove pia huondoa dependencies ambazo hazihitajiki na kitu kingine chochote, wakati apt remove huziaacha zikiwa zimesakinishwa kwa ajili ya apt autoremove ya baadaye. Kwa hivyo, kuondoa utility ndogo moja kwenye Rocky Linux kunaweza kupendekeza kuondoa maktaba kadhaa pamoja nayo. Soma orodha kabla ya kuthibitisha.

Onyesha upya metadata, angalia kinachosubiri, 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 liliondolewa kwenye archive miezi iliyopita. dnf huangalia umri wa cache yake kabla ya kila transaction 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 alias ya zamani ya amri hiyo hiyo na bado inafanya kazi.

Maelezo moja ni muhimu ikiwa unafanya scripting: 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 block 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 kitu 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 zilizo ndani ya kifurushi ambacho bado hujasakinisha, 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 unashindwa na No such command: versionlock kwenye mashine mpya. Isakinishe kwanza na sudo dnf install python3-dnf-plugin-versionlock. apt haihitaji kitu chochote cha ziada kwa apt-mark hold, kwa sababu hold ni hali ya dpkg badala ya plugin.

Mahali ambapo mabadiliko ya mfumo yanapokwama: 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 huduma hiyo.

Badala yake, dnf hutumia 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, 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 inayofanana nayo 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 plugin, si sehemu ya dnf yenyewe. Ukiuruka, mstari wa pili utashindwa 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 na ufunguo wa kusaini (signing key) katika saraka mbili tofauti.

Tofauti ya mpangilio huu huamua mahali unapotazama wakati hazina inapofanya kazi vibaya. apt huhifadhi ufafanuzi katika /etc/apt/sources.list na /etc/apt/sources.list.d/, huku funguo za kusaini zikiwa zimehifadhiwa kando chini ya /etc/apt/keyrings/. dnf huhifadhi kila kitu katika /etc/yum.repos.d/, na ufunguo ni URL iliyo ndani ya faili ya .repo, kwa hivyo kuna faili moja ya kusoma na faili moja ya kufuta. Toleo jipya la apt limeelekea kwenye muundo huo huo na fomati ya deb822, faili moja ya .sources kwa kila hazina. Ikiwa umekutana na hitilafu ya vyanzo rudufu vya deb822 kwenye Ubuntu, tayari umekutana na nusu ya tatizo hili la apt.

EPEL ndicho hifadhi (archive) inayotumiwa 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 miongozo mingi sana huchukulia 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 hakusababishi hitilafu papo hapo. Hitilafu hutokea 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 haya yote, kwa sababu hifadhi yake kuu tayari ina vitu ambavyo EPEL huleta kutoka matoleo mapya (backports). Sera ya EPEL ni kutobadilisha kamwe kifurushi ambacho RHEL inatoa, kwa hivyo kuongeza hifadhi hiyo hakubadilishi chochote ambacho tayari kimesakinishwa kwenye seva yako.

dnf history undo, kitu ambacho apt hakiwezi kufanya

dnf hurekodi kila muamala, na inaweza kujenga 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 vilivyoboreshwa 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 kwenye hazina (repository) iliyowezeshwa, kwa hivyo mara tu toleo la zamani linapoondolewa kwenye mirror, undo hushindwa na kutoa hitilafu ya not-found. Rollback pia huishia kwenye hifadhidata ya vifurushi. Faili ya usanidi iliyoandikwa upya na uboreshaji 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 kile kilichotokea kikamilifu, ikijumuisha mstari wa amri, lakini kusoma logi si sawa na kuibatilisha. Urejeshaji kwa upande wa apt ni wa mikono: endesha apt list -a nginx ili kuona ni matoleo yapi ambayo kumbukumbu bado inayo, kisha sudo apt install nginx=<exact version string> ili kuweka pin, na ongeza sudo apt-mark hold nginx ili uboreshaji unaofuata usibatilishe marekebisho yako.

Package groups have no apt equivalent

dnf can install a named set of packages in one command.

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

Older guides write dnf groupinstall "Development Tools". That alias works on dnf 4 and is gone on dnf 5, so the two-word dnf group install is the only spelling that works everywhere. Use it and stop thinking about it.

apt has no groups. Debian's closest idea is a metapackage, an otherwise empty package whose only content is a list of dependencies, such as build-essential. The practical difference is on the way out: removing a metapackage leaves its dependencies installed until you run apt autoremove, while dnf group remove takes the group's packages with it in the same transaction.

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 ni unattended-upgrades, ambacho husanidiwa ndani ya /etc/apt/apt.conf.d/50unattended-upgrades, ambapo unaorodhesha asili (origins) ambazo inaruhusiwa kuvuta masasisho kutoka kwake. Kusanidi unattended upgrades kwenye Ubuntu inashughulikia faili hiyo ya usanidi na swali la kuanzisha upya (reboot) mfumo linaloambatana nayo.

Kwenye Rocky Linux, AlmaLinux na Fedora, kifurushi ni dnf-automatic, na timer ya systemd unayowezesha 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 unit hizo hupuuza mpangilio wa apply_updates uliopo kwenye /etc/dnf/automatic.conf, kwa hivyo timer unayochagua ni muhimu zaidi kuliko kile ambacho faili ya usanidi inasema. Kusakinisha sasisho hakuanzishi upya chochote kinachoendelea kutumia code ya zamani, kwa hivyo ni vyema kuangalia ni masasisho yapi yanayohitaji reboot na yapi yanayohitaji restart ya huduma pekee kabla ya kudhani kuwa seva imefanyiwa patching.

Ili kuzuia masasisho yawe ya usalama pekee, weka upgrade_type = security ndani ya /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 matupu kwenye seva yenye masasisho yanayosubiri inamaanisha kuwa metadata haipo, na security haitasakinisha chochote.

Kwenye Fedora, dnf 5 imebadilisha jina la unit hiyo. Sasa ni dnf5-automatic.timer, na inasoma faili ileile ya /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. Angalia 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 mazoea moja yanayofaa 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 inayobaki kufanya kazi wakati 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 huja na 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 ulio wazi zaidi unatoka kwa Docker, ambayo huchapisha amri tofauti ya repository kwa kila toleo. Kwenye RHEL na mifumo inayofanana nayo, 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 hitilafu ya matumizi 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 mambo ya msingi

Kuchagua distribution ya seva kwa kutegemea tu package manager ni kigezo kisicho sahihi. dnf na apt hufanya kazi sawa, na msamiati wake hujifunza ndani ya mchana mmoja. Kinachobadilisha uzoefu wako wa mwaka mzima ni mfumo wa release uliopo nyuma ya repository. Fedora husonga kwa kasi na release fulani huacha kupata updates takriban miezi kumi na tatu baada ya kutoka, jambo ambalo ni sawa kwa workstation lakini ni usumbufu kwa seva ambayo hutaki kuijenga upya. Rocky Linux na AlmaLinux hufuata RHEL, kwa hivyo unapata muda wa support 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, hizi zote ni picha za kawaida za VPS. Chagua muda wa support 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 (cached) kabla ya kila shughuli na kupakua nakala mpya ikiwa muda wake umekwisha, kwa hivyo dnf install kwenye seva ambayo hujaitumia kwa mwezi mmoja bado huona vifurushi vya sasa. sudo dnf makecache ipo na hulazimisha upakuaji huo, lakini matumizi yake halisi ni kuhamisha muda wa kusubiri hadi wakati unaouchagua 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 kwa kawaida 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 ilichobadilisha, 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 kitu cha kusakinisha tena kutoka kwacho. Pia, hutengua mabadiliko ya vifurushi pekee. Faili la usanidi lililoandikwa upya na sasisho, au hifadhidata iliyohamishwa na huduma wakati wa kuanza kwa mara ya kwanza, hubaki kama lilivyo. 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. Thibitisha hili kwenye mashine yako kwa ls -l /usr/bin/yum. Kuandika yum install httpd huendesha dnf, kwa hivyo mafunzo ya zamani mengi bado hufanya kazi. Andika hati (scripts) na nyaraka mpya kwa kutumia dnf, kwa kuwa jina 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 hazihitajiki na kitu kingine kama sehemu ya shughuli hiyo hiyo, wakati apt remove huviacha vikiwa vimesakinishwa hadi utakapoiendesha apt autoremove kando. Kwa hivyo, uondoaji unaoonekana mdogo kwenye Ubuntu unaweza kuchapisha orodha ndefu kwenye Rocky Linux. Orodha hiyo kwa kawaida huwa 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.