Rocky ও AlmaLinux-এ EPEL ও CRB repository যোগ করার নিয়ম

আপনার প্রয়োজনীয় package dnf খুঁজে না পাওয়ার কারণ

EPEL এবং CRB হলো দুটি repository, যেগুলো নতুন Rocky Linux বা AlmaLinux server-এ ডিফল্টভাবে থাকে না। তাই নতুন server-এ dnf install htop চালালে No match for argument: htop এবং পরে Error: Unable to find a match: htop দেখা যায়। কোনো কিছু নষ্ট হয়নি এবং কোনো mirror-ও offline নয়। Base distribution ইচ্ছাকৃতভাবে অল্প কিছু package সরবরাহ করে, CRB উপস্থিত থাকলেও disabled থাকে, আর EPEL একটি আলাদা community repository, যা আপনাকে যোগ করতে হবে।

Ubuntu-তে একই package universe-এ থাকে এবং প্রায় সব cloud image-এ universe enabled থাকে। তাই সেখানে এই প্রশ্ন ওঠে না। Red Hat family package-গুলো ভিন্নভাবে ভাগ করে এবং ডিফল্টভাবে কম package অন্তর্ভুক্ত করে। সমাধানটি তিনটি command-এ করা যায়। এই guide-এর বাকি অংশে সেই বিষয়গুলো ব্যাখ্যা করা হয়েছে, যেগুলো প্রথম সপ্তাহে সাধারণত কেউ বলে না: এই repository-গুলো কী সরবরাহ করার প্রতিশ্রুতি দেয়, কী দেওয়ার প্রতিশ্রুতি দেয় না, এবং কীভাবে কোনো third-party repository-কে নীরবে আপনার base system-এর নিয়ন্ত্রণ নেওয়া থেকে আটকাবেন।

এই command-গুলো কীভাবে যাচাই করা হয়েছে। আমাদের command test container-গুলোতে শুধু Ubuntu চালানো হয়। তাই নিচের dnf command-গুলো আমাদের নিজস্ব test machine-এ চালানো হয়নি। এগুলো Rocky Linux এবং AlmaLinux-এর documentation অনুসরণ করে লেখা হয়েছে। প্রতিটি ধাপে প্রত্যাশিত output উল্লেখ করা আছে। তাই পুরো block একসঙ্গে paste না করে নিজের server-এ প্রতিটি ধাপ যাচাই করুন।

BaseOS, AppStream এবং CRB কী?

BaseOS হলো অপারেটিং সিস্টেমের মূল অংশ: kernel, glibc, systemd এবং core userland। Major release-এর পুরো জীবনচক্রে এখানকার version স্থির থাকে, এবং সেই স্থির version-গুলোর মধ্যে security fix backport করা হয়। BaseOS-এ কোনো version number বহু বছরের পুরোনো দেখালেও package-টি unpatched নয়। এটি patch করা পুরোনো version। Enterprise distribution-এর মূল উদ্দেশ্যই হলো এটি।

AppStream-এ থাকে operating system-এর ওপর চালানো software: web server, database, language runtime, editor এবং monitoring agent। Version 8-এ AppStream-এর বড় অংশ alternate stream-সহ module হিসেবে সরবরাহ করা হতো। তাই dnf module list গুরুত্বপূর্ণ ছিল, এবং আপনি, উদাহরণস্বরূপ, একটি PHP stream বেছে নিতেন। Version 9-এ প্রায় সব modularity বাদ দেওয়া হয়েছে। তাই Rocky 9 এবং Alma 9-এ সাধারণত কোনো software-এর একটি version পাওয়া যায় এবং আগে enable করার মতো কোনো module থাকে না।

Extras default হিসেবে enabled থাকে এবং এটি খুব ছোট repository। এখানে মূলত অন্যান্য repository-এর release package থাকে। epel-release নিজেও এখান থেকেই আসে। এই কারণেই Rocky বা Alma-তে EPEL install করার জন্য আপনাকে কখনো কোনো random URL বিশ্বাস করতে হয় না।

CRB হলো CodeReady Builder repository। Version 8-এ এটিকে PowerTools বলা হয়। এখানে distribution-এর build সংক্রান্ত package থাকে: development header, static library এবং build time-এ package-এর প্রয়োজন হয় এমন test ও documentation tooling। Repository-টি mirror-এ ইতিমধ্যে থাকে, কিন্তু default হিসেবে disabled। Red Hat-এর নিজস্ব product-এ একই content-কে CodeReady Linux Builder বলা হয়। এটি subscription-এর সঙ্গে আসে, তবে Red Hat জানায় যে এটি support-এর আওতাভুক্ত নয়। Rocky এবং Alma উভয়ই একই content এবং disabled default উত্তরাধিকারসূত্রে পেয়েছে।

Debian বা Ubuntu থেকে আসা পাঠকদের জন্য: main একই archive-এ runtime package এবং -dev header রাখে। তাই সেখানে CRB enable করার প্রয়োজন নেই। EPEL-এর সবচেয়ে কাছাকাছি সমতুল্য হলো universe। এটি community-maintained এবং vendor support-এর কোনো প্রতিশ্রুতি বহন করে না।

EPEL কী এবং এর পেছনে কারা আছে

EPEL-এর পূর্ণরূপ Extra Packages for Enterprise Linux। এটি Fedora-এর একটি প্রকল্প। Fedora-তে থাকা package-গুলো বর্তমান enterprise release-এর জন্য পুনর্নির্মাণ করা হয় এবং EPEL Special Interest Group এগুলো রক্ষণাবেক্ষণ করে। এই group-এ মূলত Fedora community-এর স্বেচ্ছাসেবকেরা কাজ করেন। Red Hat build ও mirror infrastructure host করে এবং কিছু Red Hat engineer এতে package রক্ষণাবেক্ষণ করেন। এর বাইরে সম্পর্কটি শেষ। EPEL কোনো Red Hat product নয়। RHEL বা কোনো rebuild-এ EPEL package-এর জন্য কোনো support contract বা SLA (service level agreement) নেই।

একটি policy-এর কারণে EPEL enable করা নিরাপদ: EPEL package কখনো base distribution-এর package প্রতিস্থাপন করতে পারবে না। AppStream-এ যদি nginx থাকে, EPEL-এ তা থাকবে না। EPEL package review করা ব্যক্তিরাই এই নিয়ম প্রয়োগ করেন। তাই এটি শুধু EPEL-এর ক্ষেত্রে প্রযোজ্য একটি অঙ্গীকার। পরে আপনি অন্য কোনো repository যোগ করলে এটি আপনাকে অন্য ঝুঁকি থেকে সুরক্ষা দেয় না।

EPEL-এর lifetime commitment-ও base distribution-এর মতো নয়। তৃতীয় বছরে এই পার্থক্যটি সমস্যার কারণ হতে পারে। BaseOS package-এর version major release-এর পুরো দশ বছরের lifetime জুড়ে স্থির থাকে। EPEL maintainer অনেক ছোট একটি সময়সীমার commitment দেন: অন্তত একটি RHEL minor release অথবা 13 মাস, যেটি কম। বাস্তবে অধিকাংশ package এর চেয়ে অনেক বেশি সময় রক্ষণাবেক্ষণ করা হয়। Maintainer কাজ ছেড়ে দিলে কিছু package retired হয়। আবার আপনার distro-এর lifetime-এর মাঝামাঝি কিছু package নতুন major version-এ চলে যেতে পারে, কারণ EPEL Fedora অনুসরণ করে। তাই একটি সাধারণ dnf upgrade এমন একটি মেশিনে EPEL tool-এর নতুন major version install করতে পারে, যেটিকে আপনি স্থিতিশীল মনে করেছিলেন। আপনি যে package-এর ওপর নির্ভর করেন, সেটিও এমন কোনো announcement ছাড়াই update পাওয়া বন্ধ করতে পারে যা আপনার কাছে পৌঁছায়।

EPEL enable করার আগে আরও একটি বিষয় জানা দরকার। EPEL সর্বশেষ RHEL minor release-এর বিরুদ্ধে build করা হয়। আপনি যদি কোনো server-কে পুরোনো minor release-এ আটকে রাখেন, frozen mirror বা vendor point release repository ব্যবহার করেন, তাহলে EPEL package আপনার system-এ থাকা version-এর চেয়ে নতুন একটি base library প্রয়োজন করতে পারে। dnf এটিকে missing dependency হিসেবে দেখায়। ফলে এটি mirror সমস্যা মনে হতে পারে, যদিও প্রকৃত কারণ version skew।

Rocky বা Alma-তে CRB সক্রিয় করুন এবং EPEL ইনস্টল করুন

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled-এর তালিকায় এখন baseos, appstream, extras, crb এবং epel থাকার কথা। একটি ছোট epel-cisco-openh264 এন্ট্রিও দেখা যেতে পারে, যা epel-release যোগ করে। ওই তালিকা থেকে crb অনুপস্থিত থাকলে enable ধাপটি কার্যকর হয়নি। এর কারণ পরের section-এ ব্যাখ্যা করা হয়েছে।

Rocky 8 এবং Alma 8-এ repository-টির নাম এখনও PowerTools। তাই মাঝের command-টি হবে sudo dnf config-manager --set-enabled powertools। Repository ID-তে uppercase এবং lowercase আলাদা হিসেবে গণ্য হয়। পুরোনো CentOS 8 documentation-এ এটি capitals-সহ PowerTools হিসেবে লেখা থাকে, যা মিলে না। AlmaLinux 10-এ 10.0 থেকে CRB repository default হিসেবে enabled থাকে (September 2025-এ পরিবর্তন করা হয়েছে)। তাই সেখানে শুধু epel-release ধাপটিই প্রয়োজন।

epel-release আসে extras থেকে, যা আগে থেকেই enabled থাকে। তাই কোনো URL trust করার বা হাতে key import করার প্রয়োজন নেই। Package-টি /etc/yum.repos.d/epel.repo লেখে এবং EPEL signing key /etc/pki/rpm-gpg/-এর অধীনে ইনস্টল করে। ওই file-এ gpgcheck=1 নিশ্চিত করুন। Signature error এড়াতে --nogpgcheck ব্যবহার করতে বলে এমন কোনো guide অনুসরণ করবেন না। Signature check ব্যর্থ হলে package-টি দাবিকৃত package নয়, অথবা আপনার system clock ভুল।

Rocky-তে epel-release /usr/bin/crb-এ একটি ছোট helper-ও ইনস্টল করে। তাই plugin ছাড়াই sudo crb enable এবং crb status একই কাজ করে। নির্ভর করার আগে command -v crb দিয়ে এটি আছে কি না পরীক্ষা করুন, কারণ প্রতিটি rebuild-এর প্রতিটি branch-এ এটি থাকে না।

শুধু তালিকায় আছে কি না নয়, EPEL থেকে package পাওয়া যাচ্ছে কি না নিশ্চিত করতে এমন একটি package-এর জন্য query করুন, যা শুধু EPEL-এই থাকে:

dnf repoquery --repo=epel htop

এতে package name, version এবং architecture দেখায়। কোনো output না থাকলে repository enabled থাকলেও কোনো তথ্য ফেরত দিচ্ছে না। সাধারণত এটি configuration সমস্যা নয়; mirror বা metadata-র সমস্যা। তাই পরের ধাপে sudo dnf clean all && sudo dnf makecache চেষ্টা করুন।

dnf কেন বলে: no such command: config-manager

এটি প্রথম যে সমস্যায় অনেকে পড়েন। VPS provider-রা যে image দেয়, ঠিক সেগুলোতেই এটি বেশি ঘটে।

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager একটি plugin, dnf-এর built-in subcommand নয়। এটি dnf-plugins-core-এ থাকে। একটি পূর্ণ server install-এ এই package সাধারণত যুক্ত থাকে। কিন্তু minimal image, cloud image এবং container image-এ এটি থাকে না। Package-টি এই virtual capability ঘোষণা করে বলে dnf-এর নিজস্ব পরামর্শটি কাজ করে:

sudo dnf install -y 'dnf-command(config-manager)'

এটি হুবহু লিখুন। Parentheses shell syntax-এর অংশ। তাই quote ছাড়া লিখলে dnf error-এর বদলে syntax error দেখা যাবে।

যে repository প্রয়োজন সেটিই যদি disabled থাকে, তাহলে plugin install করা যাবে না। সেক্ষেত্রে file-টি সরাসরি edit করুন। কোন file-এ section-টি আছে তা খুঁজে বের করুন, file-টি খুলুন এবং [crb]-এর অধীনে enabled=1 সেট করুন:

grep -rl crb /etc/yum.repos.d/

config-manager ঠিক এই পরিবর্তনই করে। তাই হাতে পরিবর্তন করলেও কিছু বাদ পড়ে না। dnf repolist --enabled ফলাফল নিশ্চিত করে।

কিছু EPEL package ইনস্টল হবে না, যতক্ষণ না CRB চালু করা হয়

দ্বিতীয় সাধারণ সমস্যায় error message-এ CRB-এর কোনো উল্লেখ থাকে না। CRB-তে থাকা কোনো library-এর ওপর নির্ভরশীল EPEL package dependency resolution-এর সময় ব্যর্থ হয়। Message-এ library এবং সেটি চাওয়া package-এর নাম দেখায়:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

কারণ হলো CRB disabled অবস্থায় আছে। তাই dnf সেই library সরবরাহকারী একমাত্র repository দেখতে পারে না। ক্রমানুসারে দুটি বিষয় পরীক্ষা করুন:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

দ্বিতীয় command-এ কোনো package-এর নাম দেখা গেলেও সাধারণ install ব্যর্থ হলে CRB বন্ধ আছে। এই ধরনের error এত সাধারণ যে AlmaLinux version 10-এ এটি বন্ধ করার জন্য CRB default হিসেবে চালু করেছে। --enablerepo=crb একটি single install-এ one-time flag হিসেবেও কাজ করে। তবে আপনি EPEL ব্যবহার করলে CRB স্থায়ীভাবে enabled রাখুন, কারণ পরবর্তী EPEL update আগে থেকে কোনো warning না দিয়েই নতুন CRB dependency আনতে পারে।

এই প্যাকেজটি কোন repository থেকে এসেছে?

চারটি repository enabled রেখে কয়েক সপ্তাহ কাজ করার পর দরকারি প্রশ্নটি আর কী installed আছে তা থাকে না; বরং প্যাকেজটি কোথা থেকে এসেছে, সেটিই গুরুত্বপূর্ণ হয়ে ওঠে।

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

কোনো installed package-এর ওপর dnf info চালালে একটি From repo line দেখা যায়। dnf list installed একই তথ্যের তৃতীয় column-এ সামনে একটি @ সহ দেখায়। তাই @epel মানে প্যাকেজটি EPEL থেকে installed হয়েছে, আর @System মানে dnf জানে না এটি কোথা থেকে এসেছে। সাধারণত এর অর্থ হলো কেউ downloaded file-এর ওপর rpm -i চালিয়েছে। repoquery line প্রতিটি repository-এর জন্য package count দেখায়। উত্তরাধিকারসূত্রে পাওয়া কোনো server-এ এমন repository থেকে চল্লিশটি package এসেছে, যার নাম আপনি কখনো শোনেননি—এটি দ্রুত শনাক্ত করার সবচেয়ে কার্যকর উপায়। শেষ command-টি একটি repository আপনাকে ঠিক কোন package দিয়েছে তা তালিকাভুক্ত করে। সেটি remove করার সিদ্ধান্ত নেওয়ার আগে এই inventory দরকার।

এখানে apt-এর প্রচলিত command হলো apt-cache policy <package>। প্রথম মাসে dnf ও apt command-এর সমতুল্য দ্বিতীয় tab-এ খোলা রাখা ভালো, কারণ flags এক না হলেও ধারণাগুলো সহজেই মিলিয়ে দেখা যায়।

তৃতীয় পক্ষের repository-কে base package প্রতিস্থাপন করা থেকে কীভাবে আটকাব?

EPEL এমনটি না করার প্রতিশ্রুতি দেয়। অন্য কোনো repository এমন নিশ্চয়তা দেয় না। Database, agent বা language runtime-এর vendor repository নিজেরাই এমন কোনো library-এর build সরবরাহ করতে পারে, যেটি BaseOS-ও দেয়। dnf সেটিই install করবে, কারণ dnf-এর default rule সহজ: যে উৎস থেকেই আসুক, সর্বোচ্চ version জয়ী হয়।

দুটি control-এর মাধ্যমেই বেশিরভাগ কাজ করা যায়। দুটিই /etc/yum.repos.d/-এর অধীনে থাকা repository file-এ থাকে।

priority= নির্ধারণ করে, একই package name একাধিক repository-তে থাকলে কোন repository অগ্রাধিকার পাবে। কম সংখ্যার অগ্রাধিকার বেশি এবং default হলো 99। তাই base repository-গুলোর জন্য কম সংখ্যা এবং তৃতীয় পক্ষের repository-র জন্য বেশি সংখ্যা দিন। তখন third party version নতুন হলেও dnf base package নেবে। আধুনিক dnf নিজেই এটি পরিচালনা করে। তাই CentOS 7 যুগের আলাদা yum-plugin-priorities package এখন আর সমাধানের অংশ নয়।

includepkgs= filter option-গুলোর মধ্যে বেশি শক্তিশালী। excludepkgs= কোনো repository থেকে নির্দিষ্ট নামের package block করে। এর জন্য repository কী কী package সরবরাহ করতে পারে, তা আগে অনুমান করতে হয়। includepkgs= এর বিপরীত কাজ করে: এই repository কেবল নির্দিষ্ট নামগুলো সরবরাহ করতে পারবে, অন্য কিছু নয়। কোনো vendor repository যদি শুধু নিজের agent সরবরাহ করে, তাহলে একটি লাইনই যথেষ্ট।

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

Version 8-এ আরও একটি setting জানা দরকার। কোনো third party repository-র package একই নামের AppStream module সরবরাহ করলে সেটি আড়াল হয়ে যেতে পারে। ওই repository-র section-এ module_hotfixes=1 ব্যবহার করলে dnf সেই filtering বন্ধ করে। কোনো package dnf repoquery-এ দেখা গেলেও 8 সংস্করণের সিস্টেমে install না হলে, সাধারণত এটাই কারণ। Version 9-এ প্রায় সব module বাদ দেওয়া হয়েছে, তাই সেখানে এটি খুব কম দেখা যায়।

একটি package-কে একটি নির্দিষ্ট version-এ স্থির রাখতে python3-dnf-plugin-versionlock install করুন এবং sudo dnf versionlock add <package> ব্যবহার করুন। এটি apt-mark hold-এর সমতুল্য। Debian থেকে আসা ব্যবহারকারীদের বিভ্রান্ত করতে পারে এমন একটি বিপরীত নিয়ম মনে রাখুন: apt-এ বেশি Pin-Priority জয়ী হয়, আর dnf-এ কম priority জয়ী হয়।

RHEL-সংলগ্ন repository মেশালে কেন server আর upgrade করা যায় না

Rocky, Alma, CentOS Stream, Oracle Linux এবং RHEL পরস্পরের এত কাছাকাছি যে একটির package অন্যটিতে install হয়। আবার তাদের মধ্যে যথেষ্ট পার্থক্যও আছে, ফলে শেষ পর্যন্ত এমন একটি system তৈরি হয় যা কেউ support করতে পারে না।

এর মূল কারণ version number। CentOS Stream 9, RHEL 9-এর চেয়ে এগিয়ে থাকে। তাই কোনো Rocky 9 box-কে Stream repository-এর দিকে নির্দেশ করলে, এমনকি একবার বা একটি package-এর জন্য করলেও, আপনার system-এ এমন package থেকে যায় যার version Rocky কখনো release করবে না। পরবর্তী Rocky minor release এলে সেই package-এর version আপনার installed version-এর চেয়ে কম থাকে। তাই dnf upgrade সেটিকে পরিবর্তন করবে না। এখন machine-এ এমন package-এর সমন্বয় চলছে যা কেউ পরীক্ষা করেনি। আপনি system patched আছে ধরে নিলেও এটি বছরের পর বছর নীরবে এমন অবস্থায় থেকে যেতে পারে।

লক্ষণ হলো dnf upgrade কোনো কাজ নেই বলে দেখায়, কিন্তু sudo dnf distro-sync অনেক package downgrade করার প্রস্তাব দেয়। distro-sync হলো মেরামতের tool। এটি installed প্রতিটি package-কে enabled repository-গুলোতে বর্তমানে উপলভ্য version-এর সঙ্গে মিলিয়ে দেয়, downgrade-ও করে। প্রথমে foreign repository disable করুন। তারপর tool-টি চালান। গ্রহণ করার আগে প্রস্তাবিত package list পড়ুন। Mirror-এ পুরোনো RPM আর না থাকলে repair ব্যর্থ হয়। তখন dependency solver নিয়ে লড়াই করার চেয়ে clean image থেকে server পুনর্নির্মাণ করা দ্রুত এবং নিরাপদ।

ELevate-এর অবশিষ্ট file আর package এই সমস্যার আরেকটি সাধারণ রূপ। ELevate হলো Leapp-এর ওপর তৈরি AlmaLinux migration tool। এটি CentOS 7 box-কে পরবর্তী version-এ নিতে বা rebuild-এর মধ্যে রূপান্তর করতে ব্যবহৃত হয়। তাড়াহুড়ো করে করা migration-এর ফলে /etc/yum.repos.d/-এ EL7 repository file থেকে যেতে পারে এবং EL7 package-ও installed থাকতে পারে। rpm -qa | grep el7 দিয়ে এগুলো খুঁজে বের করুন। প্রতিটি এমন একটি package, যেটিকে কোনো enabled repository কখনো update করতে পারবে না। পরে Leapp চালালে এগুলো এমন package হিসেবে দেখায়, যেগুলোর সঙ্গে mapping করা যায় না। এতে upgrade blocker তৈরি হয় এবং আপনাকে হাতে করে তা সরাতে হয়। Server স্থিতিশীল থাকা অবস্থায় এগুলো সরিয়ে ফেলুন। পরবর্তী major upgrade-এর দিন পর্যন্ত অপেক্ষা করবেন না।

কোনো vendor repository AppStream package-কে আড়াল করে রাখাও একই সমস্যার তুলনামূলক হালকা রূপ। উপরের includepkgs line-টি এর সমাধান। Container tooling-এ এটি সবচেয়ে বেশি দেখা যায়। কারণ Docker-এর নিজস্ব repository-এর containerd.io, AppStream-এর runc-এর সঙ্গে conflict করে। তাই দুটির একটি সরাতে হবে। একবার সিদ্ধান্ত নিন, exclusion লিখে রাখুন এবং পরীক্ষিত সঠিক ক্রম অনুসরণ করুন: Rocky Linux-এ Docker install walkthrough-এ কোন distribution package আগে সরাতে হবে তা দেওয়া আছে।

রিপোজিটরির ক্ষেত্রে apt থেকে dnf-এ অনুবাদ

• /etc/apt/sources.list.d/*.sources হয়ে যায় /etc/yum.repos.d/*.repo, যেখানে একটি ফাইলে একাধিক [sections] থাকতে পারে এবং প্রতিটির নিজস্ব id থাকে।
• add-apt-repository universe হয়ে যায় dnf install epel-release। তবে পার্থক্য হলো, universe এখনও Ubuntu-এর নিজস্ব archive-এর অংশ, আর EPEL একটি আলাদা project।
• apt update-এর সরাসরি সমতুল্য নেই—এটি মনে রাখুন। dnf নিজস্ব সময়সূচি অনুযায়ী metadata refresh করে, আর dnf makecache তাৎক্ষণিকভাবে refresh করায়।
• apt-cache policy <pkg> হয়ে যায় dnf info <pkg>। অফারে থাকা প্রতিটি version দেখতে dnf list --showduplicates <pkg> যোগ করুন।
• apt-mark hold হয়ে যায় dnf versionlock add, যা python3-dnf-plugin-versionlock থেকে নেওয়া হয়।
• /etc/apt/preferences.d/-এ pinning-এর পরিবর্তে repository section-এ priority= ব্যবহার করা হয়। এখানে সংখ্যাগুলোর দিক উল্টো।
• dpkg -S /path/to/file হয়ে যায় rpm -qf /path/to/file।

Automatic updates syntax হিসেবে নয়, ধারণা হিসেবে স্থানান্তরিত হয়, কারণ এখানে কোনো unattended-upgrades নেই। timer, config file এবং reboot করা হবে কি না—এই সিদ্ধান্ত Rocky এবং Alma-তে dnf-automatic-এ ব্যাখ্যা করা হয়েছে।

রিপোজিটরির তালিকা সংক্ষিপ্ত রাখুন

CRB সক্রিয় করুন, epel-release ইনস্টল করুন, তারপর কী করেছেন এবং কেন করেছেন তা লিখে রাখুন। এটি configuration management-এ অথবা সার্ভারের একটি সাধারণ ফাইলে রাখতে পারেন। সার্ভারটি তিন বছর পুরোনো হলে এবং অন্য কেউ এটি পরিচালনা করলে এই নোটের গুরুত্ব বোঝা যায়।

কোনো repository যোগ করার আগে অনুসন্ধান করুন। dnf search চালান, তারপর dnf info চালান। এরপরই কেবল নতুন repository যোগ করার কথা বিবেচনা করুন। মানুষ EPEL সক্রিয় করে যে প্যাকেজগুলোর একটি উল্লেখযোগ্য অংশ পেতে চায়, সেগুলোর অনেকগুলোই ইতিমধ্যে AppStream-এ আছে। System monitoring এর সবচেয়ে স্পষ্ট উদাহরণ। Performance Co-Pilot base repositories-এ সরবরাহ করা হয় এবং এর জন্য কোনো third-party repository প্রয়োজন হয় না। প্রতিটি অতিরিক্ত repository এমন একটি পক্ষ যোগ করে, যারা যেকোনো মঙ্গলবার আপনার সিস্টেমে একটি package সরবরাহ করতে পারে। এদের প্রত্যেকটি পরবর্তী major upgrade আরও কঠিন করে তোলে।

আপনি যদি এখনও দুইটি distribution-এর মধ্যে নির্বাচন করে থাকেন, তবে এই সম্পূর্ণ বিন্যাস উভয় distribution-এই একই এবং epel-release একইভাবে কাজ করে। প্রকৃত পার্থক্য অন্যত্র। Rocky Linux এবং AlmaLinux-এর তুলনা rebuild philosophy ব্যাখ্যা করে। কারণ AlmaLinux এখন line-for-line rebuild-এর পরিবর্তে ABI (application binary interface) compatibility লক্ষ্য করে।

FAQ

Rocky Linux 9 বা AlmaLinux 9-এ EPEL কীভাবে সক্রিয় করব?

প্রথমে sudo dnf install -y dnf-plugins-core, তারপর sudo dnf config-manager --set-enabled crb, এরপর sudo dnf install -y epel-release চালান। dnf repolist --enabled দিয়ে নিশ্চিত করুন; এতে baseos, appstream, extras, crb এবং epel তালিকাভুক্ত হওয়ার কথা। EPEL package ইনস্টল করার আগে CRB সক্রিয় করুন, কারণ অনেক package এমন library-এর ওপর নির্ভর করে যা শুধু CRB সরবরাহ করে। version 8-এ repository id হিসেবে crb-এর পরিবর্তে powertools ব্যবহৃত হয়।

Production server-এ EPEL সক্রিয় করা কি নিরাপদ?

EPEL ব্যাপকভাবে ব্যবহৃত হয়। এর নীতিমালা অনুযায়ী EPEL package base distribution-এর কোনো package প্রতিস্থাপন করে না। তাই এটি সক্রিয় করলে BaseOS বা AppStream-এর সরবরাহ করা package পরিবর্তিত হয় না। তবে support-এর সীমাবদ্ধতা আছে। EPEL একটি volunteer Fedora project; এর কোনো service level agreement নেই। একজন maintainer কোনো package-এর দায়িত্ব সর্বনিম্ন একটি RHEL minor release বা 13 মাসের জন্য নিতে পারেন। dnf repository-packages epel list installed দিয়ে inventory সংরক্ষণ করুন। কোনো customer-facing service EPEL package-এর ওপর নির্ভর করলে সেই package-এ dnf versionlock ব্যবহার করুন।

dnf কেন no such command: config-manager দেখায়?

কারণ config-manager dnf-এর built-in command নয়; এটি একটি dnf plugin। Minimal image বা container image-এ dnf-plugins-core না-ও থাকতে পারে। বার্তাটিই সমাধান নির্দেশ করে: sudo dnf install -y 'dnf-command(config-manager)'। Parentheses-গুলো quote করা হয়েছে, যাতে shell সেগুলোকে নিজস্ব syntax হিসেবে না পড়ে। এখন কোনো package ইনস্টল করতে না পারলে grep -rl crb /etc/yum.repos.d/ চালান, এটি যে file-এর নাম দেখায় সেটি খুলুন, এবং [crb] section-এ হাতে enabled=1 সেট করুন।

CRB এবং PowerTools-এর মধ্যে পার্থক্য কী?

দুটি নাম একই repository-কে নির্দেশ করে। version 8-এ এর নাম PowerTools এবং id powertools। version 9 ও পরবর্তী version-এ এর নাম CRB এবং id crb। Red Hat-এর নিজস্ব product-এ এই content-এর নাম CodeReady Linux Builder। এতে development header, static library এবং build-time tooling থাকে। Rocky এবং AlmaLinux 9-এ এটি defaultভাবে disabled থাকে। AlmaLinux 10-এ 10.0 থেকে এটি defaultভাবে enabled থাকে। তাই সেখানে enable command চালানোর আগে dnf repolist --enabled পরীক্ষা করুন।

কিছু নষ্ট না করে EPEL আবার কীভাবে সরাব?

প্রথমে dnf repository-packages epel list installed দিয়ে inventory তৈরি করুন। কারণ শুধু epel-release package সরালে EPEL থেকে ইনস্টল করা package সরবে না। সেগুলো disk-এ থেকে যাবে, update পাওয়ার উৎস হারাবে এবং security fix পাওয়া বন্ধ হবে—এ বিষয়ে আপনাকে কোনো error জানানো হবে না। প্রতিটি package আলাদাভাবে যাচাই করুন। যেগুলোর আর প্রয়োজন নেই, সেগুলো remove বা replace করুন। তারপর sudo dnf remove epel-release চালান। EPEL-এর কোনো package যদি অন্য কোনো package প্রতিস্থাপন না করে থাকে এবং সরাতেই হয়, sudo dnf repository-packages epel remove এক transaction-এ পুরো set পরিষ্কার করে। Confirm করার আগে প্রস্তাবিত তালিকাটি সতর্কভাবে পড়ুন।