Rocky ও Fedora-তে apt কমান্ডের dnf সমতুল্য

সংক্ষিপ্ত উত্তর

apt থেকে dnf-এ পরিবর্তন মূলত পরিভাষার পরিবর্তন। apt install nginx-এর সমতুল্য হলো dnf install nginx। apt remove nginx-এর সমতুল্য হলো dnf remove nginx। apt update-এর সরাসরি সমতুল্য নেই, কারণ cached copy পুরোনো হয়ে গেলে dnf নিজেই repository metadata refresh করে। রূপান্তরের সহজ অংশটি এক স্ক্রিনেই শেষ হয়। কার্যকর অংশটি হলো সেই চারটি operation, যেগুলোর সরাসরি সমতুল্য নেই: repository যোগ করা, একটি transaction পূর্বাবস্থায় ফিরিয়ে নেওয়া, একটি package group install করা এবং unattended update চালানো।

নিচের প্রতিটি command আপনার নিজের server-এ চালানোর জন্য লেখা। y-এর উত্তর দেওয়ার আগে dnf যে transaction summary দেখায় তা পড়ুন, বিশেষ করে removal-এর ক্ষেত্রে।

কোন কোন distro-তে dnf এবং কোন কোন distro-তে apt ব্যবহার করা হয়

Fedora, Red Hat Enterprise Linux (RHEL) এবং RHEL-এর rebuild—Rocky Linux, AlmaLinux ও CentOS Stream—এ dnf package manager হিসেবে ব্যবহৃত হয়। Debian এবং Debian থেকে উদ্ভূত সব distro-তে apt package manager হিসেবে ব্যবহৃত হয়। VPS-এর ক্ষেত্রে এর অর্থ প্রায় সব সময় Ubuntu। তৃতীয় কোনো উত্তর নেই। আপনার provider-এর image list-এ Rocky Linux বা AlmaLinux থাকলে আপনি dnf পাবেন। সেখানে Ubuntu থাকলে আপনি apt পাবেন। এই বিভাজনের এক পাশে মূলত একই system-এর জন্য চারটি নাম কেন ব্যবহৃত হয়, তা আপনি distro বেছে নেওয়ার আগে জেনে রাখা উপকারী। Red Hat Linux কীভাবে Fedora, RHEL, CentOS, Rocky এবং AlmaLinux-এ পরিণত হলো নিবন্ধে প্রতিটির উৎস ব্যাখ্যা করা হয়েছে।

Package format tool-এর সঙ্গে সামঞ্জস্যপূর্ণ। dnf .rpm file install করে এবং এর database হলো rpm। apt .deb file install করে এবং এর database হলো dpkg। তাই vendor-এর install page-এ প্রতিটি family-এর জন্য আলাদা tab থাকে। এ কারণেই কোনো project-এর release page থেকে download করা .deb Rocky Linux-এ কোনো কাজে আসে না।

আপনি যে family-ই ব্যবহার করুন, প্রথম login-এর কাজ একই। নতুন VPS-এ প্রথম দশ মিনিট উভয় ক্ষেত্রেই প্রযোজ্য। শুধু install command পরিবর্তিত হয়।

প্রতিটি apt কমান্ড এবং তার dnf সমতুল্য

Install, remove, search এবং show। উভয় দিকেই এগুলো প্রায় একই শব্দ ব্যবহার করে।

# 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 হলো dnf info। এই গ্রুপে এটিই একমাত্র পুনঃনামকরণ করা verb। তবে একটি আচরণ আলাদা, যা অনেককে সমস্যায় ফেলে। dnf remove এমন dependency-ও সরিয়ে দেয়, যেগুলো আর কোনো কিছু ব্যবহার করে না। অন্যদিকে apt remove সেগুলো পরে apt autoremove-এর জন্য ইনস্টল করা অবস্থায় রেখে দেয়। তাই Rocky Linux-এ একটি ছোট utility সরানোর সময় তার সঙ্গে এক ডজন library সরানোর প্রস্তাবও দেখা যেতে পারে। নিশ্চিত করার আগে তালিকাটি পড়ুন।

Metadata refresh করুন, কী অপেক্ষমাণ আছে তা দেখুন এবং 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-এর ক্ষেত্রে apt update বাধ্যতামূলক। কারণ apt disk-এ থাকা metadata ব্যবহার করে এবং কয়েক মাস আগে archive থেকে সরিয়ে নেওয়া কোনো version-ও সহজেই install করতে পারে। প্রতিটি transaction-এর আগে dnf তার cache কত পুরোনো তা পরীক্ষা করে এবং নিজে থেকেই নতুন metadata download করে। তাই sudo dnf makecache শুধু তখনই ব্যবহার করা হয়, যখন পরবর্তী install-এর সময় নয়, এখনই download করাতে চান।

apt পুরো system upgrade-কে দুটি ভাগে বিভক্ত করে, কিন্তু dnf তা করে না। apt upgrade কোনো installed package সরাতে অস্বীকার করে। তাই কোনো update-এর জন্য একটি package সরানো প্রয়োজন হলে এটি মাঝপথে থেমে যায়। apt full-upgrade হলো সেই version, যেটি package সরানোর অনুমতি পায়। dnf-এ এমন কোনো সীমাবদ্ধতা নেই। তাই dnf upgrade হলো apt full-upgrade-এর সমতুল্য, apt upgrade-এর নয়। dnf update একই command-এর পুরোনো alias এবং এটি এখনও কাজ করে।

আপনি script লিখলে একটি বিষয় গুরুত্বপূর্ণ: update অপেক্ষমাণ থাকলে dnf check-update status 100 দিয়ে exit করে, আর কোনো update না থাকলে 0 দিয়ে exit করে। apt list --upgradable উভয় ক্ষেত্রেই 0 দিয়ে exit করে। তাই script-কে এর output parse করতে হয়।

কোন package installed আছে তা তালিকাভুক্ত করুন এবং কোনো file-এর মালিক package খুঁজে বের করুন।

# 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

প্রতিটি block-এর শেষ line তার আগের line-গুলোর চেয়ে আলাদা প্রশ্নের উত্তর দেয়। dpkg -S এবং rpm -qf শুধু ইতিমধ্যে installed package-এ search করে। তাই এগুলোর উত্তর হলো, “এই file এখানে কোন package দিয়েছে?” apt-file search এবং dnf provides repository-তে search করে। তাই এগুলোর উত্তর হলো, “এই file পাওয়ার জন্য কোন package install করব?” apt-file Ubuntu-তে আলাদা package এবং প্রথমবার চালানোর আগে sudo apt-file update প্রয়োজন। dnf provides-এর অতিরিক্ত কিছু প্রয়োজন হয় না। তবে প্রথমবার এটি ধীর হতে পারে, কারণ উত্তর দেওয়ার জন্য dnf repository-এর file list download করে।

যে package এখনও install করা হয়নি, তার ভেতরের file-গুলোর তালিকা দেখতে dnf repoquery -l nginx ব্যবহার করুন। apt-এর ক্ষেত্রে এর সমতুল্য হলো apt-file list nginx।

Autoremove করুন, cache পরিষ্কার করুন এবং কোনো version 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

Rocky Linux বা AlmaLinux-এ versionlock default হিসেবে installed থাকে না। তাই fresh box-এ ওই line-গুলোর প্রথমটি No such command: versionlock সহ ব্যর্থ হয়। প্রথমে sudo dnf install python3-dnf-plugin-versionlock দিয়ে এটি install করুন। apt-mark hold-এর জন্য apt-এর অতিরিক্ত কিছু প্রয়োজন হয় না, কারণ hold হলো plugin নয়, বরং dpkg state।

যেখানে mapping ভেঙে যায়: একটি repository যোগ করা

এটি সেই অংশ, যার কারণে Ubuntu admin-রা এমন একটি command খুঁজতে থাকেন, যার কোনো অস্তিত্ব নেই। dnf-এ কোনো add-apt-repository নেই, এবং personal package archive (PPA)-ও নেই। PPA হলো Launchpad পরিচালিত একটি service, আর Launchpad হলো Ubuntu-এর infrastructure। RPM জগতে এমন কোনো service host করা হয় না।

এর পরিবর্তে dnf প্রতিটি repository-এর জন্য /etc/yum.repos.d/-এ একটি plain text file ব্যবহার করে। প্রতিটি file-এর শেষে থাকে .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 এবং $basearch হলো dnf variable। dnf runtime-এ আপনার major release number এবং CPU architecture বসিয়ে দেয়। তাই একই file version 9 এবং version 10, উভয় ক্ষেত্রেই কাজ করে। x86_64 এবং aarch64-এর ক্ষেত্রেও এটি কাজ করে।

বেশিরভাগ vendor ওই file প্রকাশ করে এবং আপনাকে সেটি fetch করতে বলে। RHEL এবং তার rebuild-এর জন্য Docker-এর নিজস্ব নির্দেশনায় দুটি command রয়েছে:

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

প্রথম line-টি প্রয়োজন, কারণ config-manager হলো একটি plugin; এটি dnf-এর মূল অংশ নয়। এটি বাদ দিলে দ্বিতীয় line-টি No such command: config-manager error-সহ ব্যর্থ হয়। চাইলে একই .repo file curl ব্যবহার করে নিজে download করে /etc/yum.repos.d/-এ রাখতে পারেন। ফলাফল একই হবে। VPS-এ Docker install করা-তে একই কাজের Debian পদ্ধতি দেখানো হয়েছে। সেখানে সমতুল্য ধাপে দুটি আলাদা directory-তে একটি source list এবং একটি signing key লেখা হয়।

Repository-তে সমস্যা হলে কোথায় খুঁজবেন, তা এই layout-এর পার্থক্য নির্ধারণ করে। apt definition রাখে /etc/apt/sources.list এবং /etc/apt/sources.list.d/-এ। Signing key আলাদাভাবে /etc/apt/keyrings/-এর অধীনে থাকে। dnf সবকিছু /etc/yum.repos.d/-এ রাখে, এবং key-এর URL থাকে .repo file-এর ভিতরে। তাই পড়ার জন্য একটি file এবং মুছে ফেলার জন্য একটি file থাকে। নতুন apt deb822 format-এর মাধ্যমে একই ধরনের layout-এর দিকে এগিয়েছে। সেখানে প্রতিটি repository-এর জন্য একটি .sources file থাকে। আপনি যদি Ubuntu-তে deb822 duplicate sources error-এর মুখোমুখি হয়ে থাকেন, তাহলে এই সমস্যার apt অংশটি ইতিমধ্যে দেখেছেন।

EPEL হলো অধিকাংশ গাইডে ধরে নেওয়া repository

Extra Packages for Enterprise Linux (EPEL) হলো Fedora-এর একটি project, যা RHEL এবং এর rebuild-গুলোর জন্য Fedora package তৈরি করে। এই ecosystem-এ এটিই universal PPA-এর সবচেয়ে কাছাকাছি। বিপুল সংখ্যক tutorial ধরে নেয় যে EPEL আগে থেকেই enabled আছে। কোনো package project-এর নিজস্ব website-এ দেখা গেলেও যদি dnf install, No match for argument-এর উত্তর দেয়, তাহলে প্রথমে EPEL পরীক্ষা করুন।

Rocky Linux এবং AlmaLinux-এ:

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

CRB হলো CodeReady Builder। এটি distribution-এর সঙ্গে সরবরাহ করা library-গুলোর একটি repository, কিন্তু default হিসেবে enabled থাকে না। অধিকাংশ EPEL package CRB-এর কোনো package-এর ওপর নির্ভর করে। তাই CRB ছাড়া EPEL enable করলেই সঙ্গে সঙ্গে ব্যর্থতা দেখা যায় না। পরে install করার সময় এমন package-এর unresolved dependency দেখিয়ে ব্যর্থ হয়, যার নাম আপনি আগে কখনও শোনেননি। আগে CRB enable করুন। তাহলে এই ধরনের error আর হবে না।

RHEL-এ CRB config-manager-এর মাধ্যমে নয়, subscription-এর মাধ্যমে পাওয়া যায়। তাই এই ধাপের জন্য Red Hat-এর নিজস্ব EPEL নির্দেশনা অনুসরণ করুন। Fedora-র ক্ষেত্রে এগুলোর কোনোটি প্রয়োজন হয় না, কারণ এর main repository-তেই EPEL যে package-গুলো backport করে, সেগুলো আগে থেকেই থাকে। EPEL-এর policy হলো RHEL যে package সরবরাহ করে, সেটি কখনও replace না করা। তাই repository যোগ করলেও আপনার server-এ আগে থেকেই installed কোনো কিছুর পরিবর্তন হয় না।

dnf history undo, যে কাজ apt করতে পারে না

dnf প্রতিটি transaction-এর রেকর্ড রাখে এবং একটি transaction-এর বিপরীত transaction তৈরি করতে পারে।

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

dnf history প্রতিটি transaction-এর নম্বরযুক্ত তালিকা দেখায় এবং কোন command line সেটি শুরু করেছিল তা প্রদর্শন করে। undo বিপরীত transaction তৈরি করে: ওই transaction যে package install করেছিল, সেগুলো remove করা হয়; আর যে package upgrade করেছিল, সেগুলো আপনার ব্যবহৃত আগের version-এ ফিরিয়ে নেওয়া হয়। dnf-এ switch করার পর apt ব্যবহারকারীরা এই feature-টিই সবচেয়ে বেশি মিস করেন।

এর বাস্তব সীমাবদ্ধতা আছে। এর ওপর নির্ভর করার আগে সেগুলো জানা জরুরি। undo কেবল enabled repository-তে এখনও থাকা কোনো package version পুনরায় install করতে পারে। তাই mirror থেকে পুরোনো build সরিয়ে নেওয়া হলে undo not-found error দিয়ে ব্যর্থ হয়। Rollback package database পর্যন্তই সীমিত। Upgrade কোনো config file নতুন করে লিখলে সেটি আগের অবস্থায় ফেরে না। কোনো service প্রথমবার start হওয়ার সময় database schema migrate করলে সেটিও আগের অবস্থায় ফেরে না। dnf file-গুলো ফিরিয়ে দেয়। আপনার data ফিরিয়ে দেয় না।

apt-এর সমতুল্য কোনো feature নেই। /var/log/apt/history.log command line-সহ ঠিক কী ঘটেছিল তা record করে, কিন্তু log পড়া আর সেটি undo করা এক বিষয় নয়। apt-এ recovery করতে হলে কাজটি manual: archive-এ এখনও কোন version আছে তা দেখতে apt list -a nginx চালান, তারপর একটি version pin করতে sudo apt install nginx=<exact version string> চালান এবং sudo apt-mark hold nginx যোগ করুন, যাতে পরবর্তী upgrade আপনার fix-টি আবার পরিবর্তন না করে।

Package group-এর কোনো apt সমতুল্য নেই

dnf একটি কমান্ডে নামযুক্ত প্যাকেজের সেট ইনস্টল করতে পারে।

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

পুরোনো গাইডগুলোতে dnf groupinstall "Development Tools" লেখা থাকে। এই alias dnf 4-এ কাজ করে, কিন্তু dnf 5-এ বাদ দেওয়া হয়েছে। তাই দুই-শব্দের dnf group install-ই এমন একমাত্র বানান, যা সব সংস্করণে কাজ করে। এটি ব্যবহার করুন এবং বিষয়টি নিয়ে আর ভাববেন না।

apt-এ group নেই। Debian-এ এর সবচেয়ে কাছের ধারণা হলো metapackage। এটি মূলত একটি খালি package, যার একমাত্র বিষয়বস্তু হলো dependency-র একটি তালিকা; যেমন build-essential। বাস্তব পার্থক্যটি package সরানোর সময় দেখা যায়। metapackage সরালে এর dependency-গুলো ইনস্টল অবস্থায় থেকে যায়, যতক্ষণ না আপনি apt autoremove চালান। অন্যদিকে dnf group remove একই transaction-এ group-এর package-গুলোও সরিয়ে দেয়।

unattended-upgrades এবং dnf-automatic

উভয় family-ই কোনো ব্যবহারকারী লগ ইন না থাকলেও update install করার ব্যবস্থা দেয়। উদ্দেশ্য ছাড়া এই tool-গুলোর মধ্যে আর কিছুই অভিন্ন নয়।

Ubuntu এবং Debian-এ package হলো unattended-upgrades। এটি /etc/apt/apt.conf.d/50unattended-upgrades-এ configure করা হয়, যেখানে কোন origin থেকে update নেওয়ার অনুমতি আছে তা তালিকাভুক্ত করেন। Ubuntu-এ unattended upgrades সেটআপ করা নিবন্ধে ওই configuration file এবং এর সঙ্গে সম্পর্কিত reboot-এর বিষয়টি ব্যাখ্যা করা হয়েছে।

Rocky Linux, AlmaLinux এবং Fedora-তে package হলো dnf-automatic। আপনি যে systemd timer enable করবেন, সেটিই আচরণ নির্ধারণ করে।

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

dnf-automatic-install.timer update download করে apply করে। dnf-automatic-download.timer update download করে থেমে যায়; install আপনাকেই করতে হয়। dnf-automatic-notifyonly.timer শুধু report করে। প্রতিটি unit /etc/dnf/automatic.conf-এ থাকা apply_updates setting override করে। তাই configuration file-এ যা লেখা আছে তার চেয়ে কোন timer বেছে নিচ্ছেন তা বেশি গুরুত্বপূর্ণ। Update install করলে পুরোনো code এখনও চালাচ্ছে এমন কোনো process restart হয় না। তাই system patched ধরে নেওয়ার আগে কোন update-এর জন্য reboot দরকার এবং কোনটির জন্য শুধু service restart যথেষ্ট তা পরীক্ষা করুন।

শুধু security fix-এ সীমাবদ্ধ রাখতে /etc/dnf/automatic.conf-এ upgrade_type = security সেট করুন। এই filter কাজ করার জন্য repository-গুলোকে security errata প্রকাশ করতে হয়। তাই আগে dnf updateinfo list security দিয়ে পরীক্ষা করুন। Update pending থাকা system-এ ফলাফল খালি হলে বুঝতে হবে metadata নেই। সে ক্ষেত্রে security কোনো update install করবে না।

Fedora-তে dnf 5 unit-এর নাম পরিবর্তন করেছে। নতুন নাম হলো dnf5-automatic.timer। এটি একই /etc/dnf/automatic.conf পড়ে।

yum কি এখনও কার্যকর command?

হ্যাঁ। তবে এটি নিজে থেকে কোনো কাজ করে না। Rocky Linux, AlmaLinux এবং CentOS Stream-এ /usr/bin/yum হলো dnf-কে নির্দেশ করা একটি symbolic link। আপনার সিস্টেমে এটি পরীক্ষা করুন:

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

পুরোনো yum syntax এখনও tutorial-গুলোতে দেখা যায়, কারণ এর বেশিরভাগই সরাসরি কাজ করে। yum install, yum remove এবং yum update—সবই কাজ করে। তবে একটি অভ্যাস বাদ দেওয়া ভালো: dnf 4 সিস্টেমে yum-config-manager এখনও আলাদা binary হিসেবে থাকে, কিন্তু বর্তমান documentation-এ dnf config-manager ব্যবহার করা হয়। সিস্টেমটি dnf 5-এ স্থানান্তরিত হলেও এই spelling কাজ করতে থাকবে।

dnf 4 এবং dnf 5: কোনো command কপি করার আগে যাচাই করুন

dnf 5 হলো নতুন করে লেখা সংস্করণ। এতে কয়েকটি command-এর বানান পরিবর্তন করা হয়েছে। Fedora 41 এবং পরবর্তী সংস্করণে এটি dnf হিসেবে দেওয়া হয়। Enterprise rebuild-গুলোতে পরিবর্তনটি ধীরে হয়েছে। তাই distribution-এর নাম দেখে অনুমান করবেন না। নিজের server-এ dnf --version চালিয়ে প্রথম লাইনটি পড়ুন। ওই version number-ই নির্ধারণ করবে নিচের কোন syntax আপনার প্রয়োজন।

এর সবচেয়ে পরিষ্কার উদাহরণ Docker-এর ক্ষেত্রে দেখা যায়। Docker প্রতিটি সংস্করণের জন্য আলাদা repository command প্রকাশ করে। RHEL এবং তার rebuild-গুলোতে, dnf 4 ব্যবহার করলে:

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

Fedora-তে, dnf 5 ব্যবহার করলে:

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

Vendor একই, কাজ একই, কিন্তু command আলাদা। dnf 5-এ config-manager subcommand-ভিত্তিক tool-এ পরিবর্তিত হয়েছে। তাই পুরোনো --add-repo flag গ্রহণ করা হয় না। এর বদলে repository তৈরি না হয়ে usage error দেখা যায়। আরেকটি পরিবর্তন repository enable করার ক্ষেত্রে: dnf 4-এর dnf config-manager --set-enabled crb, dnf 5-এ dnf config-manager setopt crb.enabled=1 হয়েছে।

যে সিদ্ধান্তটি আসলে গুরুত্বপূর্ণ

শুধু package manager-এর ওপর ভিত্তি করে server distribution বেছে নেওয়া ভুল মানদণ্ড। dnf এবং apt একই কাজ করে, আর এই পরিভাষা শিখতে একটি বিকেলই যথেষ্ট। আপনার পুরো বছরের ব্যবস্থাপনায় যে বিষয়টি পরিবর্তন আনে, তা হলো repository-এর পেছনের release model। Fedora দ্রুত পরিবর্তিত হয়, এবং কোনো release প্রকাশের প্রায় তেরো মাস পর সেটির update পাওয়া বন্ধ হয়ে যায়। workstation-এর জন্য এটি ঠিক আছে, কিন্তু যে server পুনরায় তৈরি করতে চান না তার জন্য এটি সমস্যাজনক। Rocky Linux এবং AlmaLinux RHEL অনুসরণ করে। তাই আপনি দশ বছরের support window এবং ইচ্ছাকৃতভাবে অপরিবর্তিত রাখা package version পান। Ubuntu উভয় ধরনের release দেয়, আর server-এ Ubuntu LTS এবং interim release-এর পার্থক্য apt জগতের একই সিদ্ধান্ত।

August 2026 অনুযায়ী, এগুলো সবই সাধারণ VPS image। আপনার প্রয়োজনীয় support window বেছে নিন। এরপর উপরের দশটি command শিখুন।

FAQ

apt update-এর সমতুল্য dnf কমান্ড কী?

কোনো কমান্ড চালানোর প্রয়োজন নেই। প্রতিটি transaction-এর আগে dnf তার cached metadata কত পুরোনো তা পরীক্ষা করে। metadata-এর মেয়াদ শেষ হলে এটি নতুন কপি ডাউনলোড করে। তাই এক মাস ধরে যেই সার্ভারে কাজ করেননি, সেখানেও dnf install বর্তমান package দেখতে পায়। sudo dnf makecache কমান্ডটি আছে এবং এটি ওই download বাধ্যতামূলক করে। তবে এর মূল ব্যবহার হলো পরবর্তী install-এর সময় delay না রেখে আপনার নির্ধারিত সময়ে তা ঘটানো। “আমার জন্য কী অপেক্ষা করছে” তা দেখার কমান্ড হলো dnf check-update। এটি apt list --upgradable-এর সমতুল্য এবং update উপলভ্য থাকলে status 100 দিয়ে শেষ হয়।

Rocky Linux বা Fedora-তে PPA-এর সমতুল্য কী?

কিছু নেই। Personal package archive হলো Launchpad-এর service, আর Launchpad হলো Ubuntu-এর infrastructure। তাই add-apt-repository-এর অনুবাদযোগ্য কোনো সমতুল্য নেই। RPM-এর সমতুল্য হলো /etc/yum.repos.d/-এর একটি .repo file। এতে একটি name, একটি baseurl এবং একটি gpgkey থাকে। Vendor-রা আপনার জন্য ওই file প্রকাশ করে। dnf 4-এ sudo dnf config-manager --add-repo <url> অথবা dnf 5-এ sudo dnf config-manager addrepo --from-repofile <url> এটি নির্দিষ্ট স্থানে download করে। সাধারণ অতিরিক্ত software-এর ক্ষেত্রে সাধারণত EPEL ব্যবহার করা হয়। sudo dnf config-manager --set-enabled crb-এর পরে sudo dnf install epel-release চালিয়ে এটি enable করুন।

কোনো dnf upgrade-এর কারণে সার্ভার নষ্ট হলে কি তা ফিরিয়ে নেওয়া যায়?

হ্যাঁ, কিছু সীমার মধ্যে। Transaction number খুঁজতে sudo dnf history চালান। ঠিক কী পরিবর্তন হয়েছে তা দেখতে sudo dnf history info <id> চালান। এরপর sudo dnf history undo <id> চালান। কোনো enabled repository-তে পুরোনো package version আর না থাকলে undo ব্যর্থ হবে, কারণ পুনরায় install করার মতো কিছু dnf-এর কাছে থাকবে না। এটি শুধু package-এর পরিবর্তন ফিরিয়ে নেয়। Upgrade-এর কারণে কোনো configuration file নতুন করে লেখা হলে, অথবা service প্রথমবার start হওয়ার সময় কোনো database migrate হলে, সেই পরিবর্তন আগের অবস্থায় ফিরবে না। apt-এ এর কোনো সমতুল্য কমান্ড নেই। সেখানে শুধু /var/log/apt/history.log-এর record থাকে।

Rocky Linux এবং AlmaLinux-এ কি yum এখনও কাজ করে?

কাজ করে, কারণ /usr/bin/yum হলো dnf-এর একটি symbolic link। নিজের system-এ ls -l /usr/bin/yum চালিয়ে এটি নিশ্চিত করুন। yum install httpd লিখলে dnf চালু হয়। তাই পুরোনো tutorial-গুলো বেশিরভাগ ক্ষেত্রেই এখনও কাজ করে। নতুন script ও documentation-এ dnf ব্যবহার করুন, কারণ yum নামটি শুধু compatibility-এর জন্য রাখা হয়েছে। পুরোনো yum-config-manager binary-এর বদলে dnf config-manager ব্যবহার করুন।

dnf remove এত package মুছে ফেলতে চায় কেন?

কারণ একই transaction-এর অংশ হিসেবে dnf এমন dependency সরিয়ে দেয়, যেগুলো আর কোনো package-এর প্রয়োজন নেই। অন্যদিকে apt remove-এর কারণে সেগুলো installed থাকে, যতক্ষণ না আলাদাভাবে apt autoremove চালান। তাই Ubuntu-তে ছোট মনে হওয়া কোনো removal Rocky Linux-এ দীর্ঘ package list দেখাতে পারে। তালিকাটি সাধারণত সঠিক হয়, তবে confirm করার আগে পড়ে নিন। তালিকায় থাকা কোনো package আপনি রাখতে চাইলে আগে সেটি explicitly install করুন। এতে dnf package-টিকে স্বতন্ত্রভাবে প্রয়োজনীয় হিসেবে record করবে।