مدیریت پکیج در لینوکس چیست؟ آموزش APT، DPKG، DNF و RPM

فرض کن روی یه سرور اوبونتو دستور jq رو می‌زنی و پیام command not found می‌بینی. روی یه سرور دیگه همین دستور کار می‌کنه. اولین کاری که می‌کنی چیه؟ می‌ری توی اینترنت دنبال یه دستور نصب می‌گردی یا اول بررسی می‌کنی چه بسته‌ای نصبه و از کجا اومده؟ من می‌خوام توی این درس عادت دوم رو با هم تمرین کنیم. چون مدیریت پکیج در لینوکس از جایی شروع می‌شه که قبل از نصب یا آپدیت، می‌فهمی سیستم الان چه وضعیتی داره.

برای مدیریت پکیج در لینوکس با چهار ابزار مهم سروکار داریم: apt، dpkg، dnf و rpm. این‌ها چهار اسم برای یک دستور واحد نیستن؛ هرکدوم توی خانواده مشخصی از توزیع‌ها و در یک سطح خاص کار می‌کنن. توی این آموزش مدیریت پکیج لینوکس یاد می‌گیری اول توزیع و مخزن رو تشخیص بدی، بعد بسته و وابستگی‌هاش رو بررسی کنی و فقط وقتی مطمئن شدی، سراغ تغییر واقعی بری.

برای اینکه بحث فقط حفظ‌کردن گزینه‌های دستورها نباشه، یه داستان فرضی داریم: تیم «اتاق تحویل صدا» فایل‌های مصاحبه رو برای تدوین آماده می‌کنه. روی یک ماشین Ubuntu و یک ماشین Fedora می‌خواد فایل JSON رو با jq بخونه؛ ولی وضعیت نرم‌افزار روی این دو سیستم فرق داره. با همین مسئله هم مدیریت بسته در اوبونتو رو می‌بینیم، هم با روش بررسی بسته‌ها در فدورا آشنا می‌شیم؛ بدون اینکه مجبور باشیم روی سرور واقعی چیزی رو خراب کنیم.

مدیریت پکیج در لینوکس چیست و اصلاً چه مشکلی رو حل می‌کنه؟

ببین، وقتی می‌خوای یه برنامه نصب کنی، فقط فایل اجراییش مهم نیست. باید بدونی نسخه مناسب کدومه، از چه منبعی میاد، چه کتابخانه‌هایی لازم داره و بعداً چطوری آپدیت می‌شه. سیستم مدیریت بسته در لینوکس این اطلاعات رو کنار هم نگه می‌داره تا مجبور نباشی هر فایل رو جداگانه از سایت‌های مختلف پیدا کنی. البته تصمیم آخر هنوز با خودته؛ ابزار فقط کمک می‌کنه آگاهانه‌تر تصمیم بگیری.

برای همین می‌گم مدیریت پکیج در لینوکس معادل «هرچی خواستم با یه دستور نصب کنم» نیست. یه مخزن اشتباه، یه نسخه ناسازگار یا یه تأیید عجولانه می‌تونه روی بقیه برنامه‌ها هم اثر بذاره. مدیریت بسته در لینوکس یعنی قبل از نصب، نسخه و منبع رو ببینی؛ قبل از حذف، لیست وابستگی‌ها رو بخونی؛ و بعد از هر تغییری، نتیجه واقعی برنامه رو تست کنی.

پکیج یا Package دقیقاً چیه؟ فرقش با برنامه و مخزن چیه؟

اول خود پکیج رو بشناسیم. یه برنامه ممکنه فایل اجرایی، کتابخانه، مستندات و فایل پیکربندی داشته باشه. توزیع لینوکس این اجزا رو توی واحدی به اسم Package بسته‌بندی می‌کنه تا ابزار مدیریت بسته بتونه وضعیتشون رو پیگیری کنه. بعضی پکیج‌ها اصلاً برنامه‌ای برای اجرا ندارن و فقط کتابخانه یا فونت هستن. پس وقتی می‌گیم آموزش نصب نرم افزار در لینوکس، همیشه منظورمون نصب یه اپلیکیشن گرافیکی نیست.

حالا احتمالاً می‌پرسی «مخزن لینوکس چیست؟». Repository در لینوکس همون منبع سازمان‌یافته‌ایه که فهرست بسته‌ها، نسخه‌ها و اطلاعات لازم برای دریافتشون رو ارائه می‌ده. مدیر بسته از روی این اطلاعات تصمیم می‌گیره کدوم نسخه قابل انتخابه و چه وابستگی‌هایی لازمه. فرق مخزن با یه لینک دانلود تصادفی همینه: بسته‌ها در چارچوب سیاست‌ها و اطلاعاتی که توزیع یا ارائه‌دهنده مخزن تعریف کرده، بررسی می‌شن؛ البته این به معنی بی‌خطر بودن مطلق هر مخزنی نیست.

یه اشتباه رایج اینه که فکر کنیم هر فایل .deb روی هر Debian یا Ubuntu نصب می‌شه و هر .rpm هم روی همه توزیع‌های خانواده RPM جواب می‌ده. نه! معماری سیستم، نسخه کتابخانه‌ها، نسخه توزیع و منشأ فایل مهمن. توی مدیریت پکیج در لینوکس، پسوند بسته فقط بهت می‌گه با چه قالبی طرفی؛ سازگاری و اعتماد رو باید جدا بررسی کنی.

اول از همه بفهم کدوم لینوکس جلوی توئه

قبل از اینکه وارد آموزش apt یا آموزش dnf بشیم، باید یه چیز ساده رو بدونی: اصلاً کدوم توزیع جلوی ماست؟ دو دستور پایین فقط اطلاعات می‌خونن؛ اولی مشخصات توزیع رو می‌ده و دومی معماری پردازنده رو. همین دو جواب تعیین می‌کنن دستورهای بعدی رو از کدوم خانواده انتخاب کنیم. از همون اول کاری نکن که یه دستور مخصوص اوبونتو رو بی‌فکر روی فدورا اجرا کنی.

cat /etc/os-release
uname -m

توی فایل /etc/os-release معمولاً شناسه‌هایی مثل ID و ID_LIKE رو می‌بینی. این اطلاعات برای انتخاب مدیر بسته خیلی کمک می‌کنن، ولی همیشه به‌تنهایی تمام جزئیات رو نشون نمی‌دن. برای مثال، آموزش مدیریت بسته در دبیان و اوبونتو معمولاً با APT جلو می‌ره، اما توزیع‌های دیگه ممکنه ابزار خودشون رو داشته باشن. پس قبل از کپی‌کردن دستور، سیستم خودت رو بشناس.

تفاوت APT و DPKG با DNF و RPM در یک نگاه

اینجا تفاوت مهم رو یک بار روشن کنیم: روی Ubuntu و Debian معمولاً apt برای کار با مخزن و وابستگی‌ها استفاده می‌شه و dpkg در سطح بسته‌های DEB کار می‌کنه. در Fedora و خانواده Red Hat هم dnf و rpm نقش‌های مشابهی در دو سطح متفاوت دارن. توی این درس هم تفاوت apt و dpkg رو می‌بینیم، هم تفاوت dnf و rpm رو؛ چون قاطی کردن این نقش‌ها موقع نصب و عیب‌یابی خیلی دردسرسازه.

اگر هدفت آموزش LPIC-1 هست، نباید فقط دستورات یک خانواده رو بلد باشی. در اهداف نسخه ۵ آزمون، مبحث ۱۰۲.۴ درباره ابزارهای Debian و مبحث ۱۰۲.۵ درباره RPM، YUM و Zypper هست؛ آشنایی با DNF هم خواسته شده. اینجا Linux Package Management رو از زاویه حل مسئله یاد می‌گیریم، نه صرفاً یک جدول حفظی. برای تمرین عملی می‌تونی دو ماشین مجازی جدا داشته باشی تا مخزن‌های خانواده‌های مختلف رو با هم قاطی نکنی.

یک داستان کوتاه : چرا روی دو سرور، یک برنامه نتیجه یکسان نمی‌ده؟

برگردیم به «اتاق تحویل صدا». مسئول ماشین اوبونتو jq --version رو می‌زنه و می‌شنوه command not found. مسئول ماشین Fedora هم نسخه‌ای از jq رو می‌بینه، ولی مطمئن نیست همون نسخه‌ایه که پروژه لازم داره. اینجاست که مدیریت پکیج در لینوکس به درد می‌خوره: قبل از اینکه درباره نصب تصمیم بگیری، باید فرق «پیدا نشدن فرمان»، «نصب نبودن بسته» و «ناسازگار بودن نسخه» رو بفهمی.

روی Ubuntu ممکنه ابزار نصب نشده باشه، شاید مسیرش توی PATH نباشه یا اصلاً فرمان رو با اسم اشتباه زده باشیم. روی Fedora هم دیدن خروجی --version لزوماً نشون نمی‌ده فایل از کدوم Repository اومده. پس فعلاً خبری از اجرای کورکورانه دستور نصب نیست. اول سرنخ‌ها رو جمع می‌کنیم و بعد روش درست آموزش نصب نرم افزار در لینوکس رو روی همین مثال جلو می‌بریم.

پنج سؤال قبل از نصب یا آپدیت هر بسته

من برای هر بار نصب یا حذف، پنج سؤال ثابت دارم: کدوم توزیعه؟ اسم بسته چیه؟ نسخه نصب‌شده کدومه؟ نسخه پیشنهادی از چه مخزنی میاد؟ و اجرای دستور دقیقاً چه چیزهایی رو عوض می‌کنه؟ همین پنج سؤال ستون اصلی مدیریت پکیج در لینوکس هستن. قرار نیست قبل از هر نصب یه مقاله بخونی؛ فقط یاد بگیر چند ثانیه فکر کردن قبل از Enter می‌تونه جلوی چند ساعت عیب‌یابی رو بگیره.

سؤال اول : اسم فرمان با اسم بسته یکیه؟

اسم دستور همیشه با اسم پکیج برابر نیست. ممکنه یک بسته چند فرمان داشته باشه یا یه فرمان از چند روش نصب در دسترس باشه. با command -v می‌تونی ببینی Shell چه مسیری رو برای اجرای فرمان پیدا می‌کنه، اما این دستور نمی‌گه فایل متعلق به کدوم بسته‌ست. توی مدیریت بسته در لینوکس باید مسیر فرمان و مالکیت بسته رو دو سؤال جدا بدونی؛ کمی جلوتر هم با DPKG و RPM این تفاوت رو می‌بینیم.

command -v jq || printf 'jq is not on PATH\n'
command -v apt || true
command -v dnf || true

سؤال دوم : نسخه نصب‌شده و نسخه پیشنهادی یکی هستن؟

وقتی بسته از قبل نصبه، سؤال بعدی اینه: نسخه‌ای که داری با نسخه‌ای که مخزن پیشنهاد می‌ده یکیه؟ توی مدیریت بسته در دبیان، apt-cache policy برای همین بررسی خیلی به کار میاد. باهاش مقدارهای Installed و Candidate و منابع قابل انتخاب رو می‌بینی. این اطلاعات بهت کمک می‌کنه تصمیم بگیری آیا اصلاً آپدیت لازم داری یا نه؛ هنوز هیچ فایلی تغییر نکرده.

سؤال سوم : منبع دریافت نسخه کجاست؟

اضافه کردن Repository یعنی پای یه منبع جدید رو به تصمیم‌گیری مدیر بسته باز کردی. مخصوصاً توی مدیریت بسته در اوبونتو، اضافه‌کردن مخزن مربوط به نسخه دیگه می‌تونه باعث بشه بعضی کتابخانه‌های اصلی هم از منبع جدید پیشنهاد بشن. پس وقتی کسی می‌پرسه «مخزن لینوکس چیست و چرا مهمه؟»، جوابش فقط آدرس دانلود نیست؛ بحث اعتماد، نسخه و سازگاری کل سیستم وسطه.

سؤال چهارم : وابستگی‌های این بسته چی هستن؟

فرض کن برای نصب یه ابزار کوچیک، مدیر بسته می‌گه سه کتابخانه دیگه هم لازمه. نباید فقط به اندازه دانلود نگاه کنی. ممکنه نسخه یکی از وابستگی‌ها تغییر کنه یا بسته‌ای قابل حذف بشه. توی آموزش apt یاد می‌گیری قبل از نصب با شبیه‌سازی، لیست تغییرات رو ببینی. این‌طوری مدیریت پکیج در لینوکس از «امیدوارم درست بشه» تبدیل می‌شه به «می‌دونم قراره چه کاری انجام بشه».

سؤال پنجم : بعد از تغییر چطور مطمئن می‌شم مشکل حل شده؟

بعد از نصب هم کار تموم نشده. مدیر بسته ممکنه بگه تراکنش موفق بوده، ولی خود برنامه خطای اجرا داشته باشه یا سرویسش بالا نیاد. توی مدیریت بسته در لینوکس باید نتیجه رو از دو طرف ببینی: گزارش نصب و رفتار واقعی نرم‌افزار. اگر سرویس مشکل داشت، از اینجا به درس مدیریت سرویس‌ها با systemd وصل می‌شیم؛ اونجا یاد گرفتیم وضعیت سرویس رو با systemctl و لاگ بررسی کنیم.

آموزش APT در اوبونتو و دبیان : از جست‌وجو تا انتخاب نسخه

بریم سراغ آموزش apt در Debian و Ubuntu. ابزار apt برای کار تعاملی خیلی خوش‌دسته: می‌تونی بسته رو جست‌وجو کنی، جزئیاتش رو بخونی و درباره نصب یا ارتقا تصمیم بگیری. اگر قراره کار رو توی اسکریپت خودکار انجام بدی، معمولاً apt-get و ابزارهای پایدارتر خط فرمان انتخاب مناسب‌تری هستن. فعلاً تمرکزمون روی یادگرفتن دستور apt در لینوکس بدون تغییر ناخواسته سیستمه.

جست‌وجوی بسته با apt search و دیدن جزئیات با apt show

apt search '^jq$'
apt show jq

با apt search دنبال نام بسته می‌گردیم و با apt show اطلاعاتش رو می‌خونیم. این دو دستور چیزی نصب نمی‌کنن؛ از فهرست شناخته‌شده مخزن‌ها کمک می‌گیرن. اگر روی دو ماشین نتیجه متفاوت بود، اول وضعیت Repository و تازه بودن فهرست‌ها رو بررسی کن. این پایه آموزش apt هست: قبل از نصب بفهمی بسته‌ای که پیدا کردی دقیقاً چیه و چه وابستگی‌هایی داره.

فرق apt update و apt upgrade؛ اشتباهی که خیلی‌ها می‌کنن

یکی از پرتکرارترین سؤال‌ها در آموزش apt، تفاوت apt update و apt upgrade هست. دستور apt update فهرست اطلاعات بسته‌ها رو از مخزن‌های تعریف‌شده تازه می‌کنه؛ خودش نسخه برنامه‌های نصب‌شده رو عوض نمی‌کنه. ولی apt upgrade سراغ ارتقای بسته‌ها می‌ره. apt full-upgrade هم ممکنه برای حل وابستگی‌ها بسته‌ای رو حذف کنه. پس روی سرور، این سه دستور رو یکی فرض نکن و همیشه قبل از تأیید، خلاصه تغییرات رو بخون.

یه نکته ریز ولی مهم: apt upgrade و apt-get upgrade همیشه رفتار یکسانی ندارن. اولی در بعضی شرایط می‌تونه بسته جدید لازم برای وابستگی رو اضافه کنه، بدون اینکه بسته نصب‌شده‌ای رو برای اون عملیات حذف کنه. بنابراین موقع آموزش دستور apt در لینوکس نباید فقط اسم گزینه رو حفظ کنی؛ باید بدونی ابزار در نسخه توزیع خودت چه سیاستی برای ارتقا داره.

چطور نسخه Installed و Candidate رو ببینیم؟

apt-cache policy bash
apt list --installed bash 2>/dev/null

برای اینکه مفهوم نسخه رو لمس کنی، از بسته bash کمک می‌گیریم که روی خیلی از ماشین‌ها موجوده. در خروجی apt-cache policy مقدار Installed نسخه فعلیه و Candidate نسخه‌ایه که APT با توجه به مخزن‌ها و اولویت‌ها انتخاب می‌کنه. این قسمت از مدیریت پکیج در لینوکس مخصوصاً وقتی کاربرد داره که می‌پرسی «چرا سیستم من نسخه جدیدتر رو پیشنهاد نمی‌ده؟». جواب رو باید توی منبع و سیاست انتخاب نسخه پیدا کنی، نه حدس بزنی.

چطور بدون نصب واقعی، یک عملیات رو پیش‌نمایش کنیم؟

apt-get -s install jq

ببین، گزینه -s در apt-get -s install jq یعنی شبیه‌سازی. ابزار براساس وضعیت فعلی اطلاعات بسته‌ها می‌گه اگر نصب رو درخواست بدی، چه تغییراتی احتمالاً انجام می‌شن. نصب واقعی اتفاق نمی‌افته، ولی این خروجی هم تضمین نمی‌کنه که تراکنش بعدی در یک زمان دیگه عیناً همین باشه. توی مدیریت بسته در دبیان این روش برای بررسی وابستگی‌ها قبل از نصب خیلی کمک می‌کنه؛ مخصوصاً روی ماشینی که نمی‌خوای بی‌برنامه تغییرش بدی.

اگر همین شبیه‌سازی رو برای بسته‌ای اجرا کنی که از قبل نصبه، ممکنه ابزار بگه کاری برای انجام دادن نداره؛ روی ماشین دیگه شاید چند بسته جدید پیشنهاد بشه. خروجی به مخزن‌ها، نسخه‌ها و وضعیت فعلی همون سیستمی که دستته بستگی داره. هدف تمرین این نیست که همه دقیقاً یه جواب ببینن؛ می‌خوام بتونی خروجی رو بخونی و توضیح بدی چرا مدیر بسته چنین تصمیمی گرفته.

نصب، حذف و پاک‌سازی تنظیمات در APT چه فرقی دارن؟

# فقط برای مطالعه؛ روی VM شخصی و بعد از بررسی خلاصه عملیات
sudo apt install jq
sudo apt remove jq
sudo apt purge jq

توی آموزش نصب نرم افزار در لینوکس فقط install رو یاد نمی‌گیریم؛ باید فرق remove و purge رو هم بدونی. remove بسته رو حذف می‌کنه و ممکنه بعضی تنظیمات مدیریت‌شده باقی بمونن؛ purge برای حذف تنظیمات مربوط به بسته هم استفاده می‌شه. اما هیچ‌کدوم به معنی پاک‌شدن تمام فایل‌های شخصی کاربر نیستن. قبل از حذف هر پکیج، مخصوصاً روی سرور، فهرست بسته‌هایی رو که قرار است حذف بشن بخون.

آموزش DPKG؛ وقتی به‌جای مخزن با خود فایل DEB کار داری

حالا نوبت آموزش dpkg هست. اینجا دیگه بیشتر با خود بسته‌های .deb و پایگاه داده بسته‌های نصب‌شده سروکار داریم. فرق مهمش با APT اینه که dpkg خودش مثل مدیر مخزن، زنجیره وابستگی‌ها رو از Repository حل و دانلود نمی‌کنه. پس تفاوت apt و dpkg فقط چند گزینه متفاوت نیست؛ یکی برای مدیریت سطح بالاتر بسته‌ها و وابستگی‌ها مناسبه و اون یکی ابزار پایه پردازش بسته‌هاست.

با dpkg-query بفهم چه بسته‌ای نصب شده

dpkg-query -W -f='${binary:Package} ${Version} ${Status}\n' bash

اگر بخوای ببینی بسته‌ای مثل bash واقعاً توی پایگاه داده DPKG چه وضعیتی داره، dpkg-query جواب می‌ده. خروجی install ok installed یعنی از نظر پایگاه داده بسته نصب شده؛ نه اینکه خود برنامه رو تست کردیم و سالم بودنش ثابت شده. توی آموزش dpkg یادت باشه همیشه «ثبت‌شدن نصب» رو از «درست اجرا شدن» جدا کنی.

از کجا بفهمیم فایل /usr/bin/bash متعلق به کدوم بسته‌ست؟

dpkg-query -S /usr/bin/bash
dpkg-query -L bash | head -20

این قسمت از مدیریت بسته در دبیان حسابی کاربردیه: با dpkg-query -S می‌پرسی یه فایل ثبت‌شده متعلق به کدوم بسته‌ست و با dpkg-query -L فهرست فایل‌های همون بسته رو می‌بینی. فقط حواست به مسیرهای /bin و /usr/bin باشه؛ روی بعضی سیستم‌ها یکی به دیگری لینک شده. اگه مسیر دقیقی که جست‌وجو کردی جواب نداد، قبل از نتیجه‌گیری مسیر واقعی فایل رو بررسی کن.

نصب فایل محلی .deb : چرا همیشه dpkg -i انتخاب خوبی نیست؟

# الگوی آموزشی؛ فایل واقعی باید معتبر و سازگار باشد
sudo dpkg -i ./software.deb
# در سیستم‌های سازگار، APT می‌تواند وابستگی فایل محلی را مدیریت کند
sudo apt install ./software.deb

فایل software.deb داخل مثال، اسم ساختگیه؛ پس دستوری که بالا دیدی برای اجرای فوری نیست. اگر یک فایل DEB معتبر و سازگار از منبع قابل اعتماد داری، معمولاً apt install ./software.deb به خاطر بررسی وابستگی‌ها انتخاب مناسب‌تری از dpkg -i تنهاست. این هم یه کاربرد عملی تفاوت apt و dpkg؛ البته هیچ‌کدوم امنیت فایلی رو که از جای ناشناخته گرفتی تضمین نمی‌کنن.

Repository در APT کجا تعریف می‌شه؟ و چرا نباید بی‌فکر اضافه‌اش کنیم؟

بریم سراغ مخزن‌ها. شاید توی یه آموزش قدیمی دیده باشی که نوشته همه منابع APT داخل /etc/apt/sources.list هستن. ولی توزیع‌های جدید می‌تونن فایل‌هایی با پسوند .list یا .sources رو هم زیر /etc/apt/sources.list.d/ نگه دارن. اگه دنبال جواب «Repository در لینوکس کجاست؟» هستی، اول باید خانواده مدیر بسته رو مشخص کنی؛ این مسیرها مربوط به APT هستن، نه همه توزیع‌ها.

ls -l /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
apt-cache policy bash

وقتی بسته‌ای از منبع نامنتظره پیشنهاد می‌شه، راه درست پاک‌کردن تصادفی فایل‌های مخزن نیست. اول با apt-cache policy نسخه‌های شناخته‌شده و اولویت‌ها رو بررسی کن و بعد فایل‌های Sources رو بخون. در مدیریت بسته در اوبونتو و دبیان، قاطی‌کردن مخزن‌های نسخه‌های ناسازگار ممکنه کتابخانه‌های اصلی رو هم درگیر کنه. پس قبل از اضافه یا حذف کردن یک Repository، دقیق بفهم چه تأثیری روی انتخاب نسخه‌ها می‌ذاره.

آموزش DNF و RPM در فدورا، راکی و خانواده Red Hat

حالا برسیم به آموزش dnf و آموزش rpm روی ماشین Fedora. اینجا بسته‌ها معمولاً قالب .rpm دارن. ابزار rpm اطلاعات بسته و فایل‌های نصب‌شده رو بررسی می‌کنه؛ dnf هم برای کار با مخزن‌ها، نصب و وابستگی‌ها به کار می‌ره. پس تفاوت dnf و rpm رو از همین اول کنار هم یاد بگیر. بعضی سیستم‌ها هنوز دستور yum رو هم دارن و در Fedoraهای جدیدتر تفاوت‌های DNF4 و DNF5 مهم می‌شه.

جست‌وجو و نمایش اطلاعات بسته با DNF

dnf search jq
dnf info jq
dnf list --installed jq

برای شروع آموزش dnf سه کار رو تمرین می‌کنیم: جست‌وجوی jq، دیدن اطلاعاتش و بررسی اینکه نصب هست یا نه. خروجی این دستورها بسته به DNF4 یا DNF5 و مخزن‌های فعال ممکنه متفاوت باشه. اگر روی سیستم تو گزینه‌ای جواب نداد، اول dnf --version و راهنمای نسخه نصب‌شده رو ببین. برای یادگرفتن مدیریت پکیج در لینوکس لازم نیست مدیر بسته خانواده دیگه رو روی سیستم شخصی نصب کنی.

فایلی که اجرا می‌شه مال کدوم RPM است؟

rpm -q jq
rpm -qf /usr/bin/bash
rpm -ql bash | head -20

در آموزش rpm اول با دستورهای فقط‌خواندنی شروع کن. rpm -q درباره وجود بسته نصب‌شده می‌پرسه، rpm -qf مالک فایل رو پیدا می‌کنه و rpm -ql فایل‌های ثبت‌شده برای بسته رو نشون می‌ده. این همون ایده‌ایه که توی آموزش dpkg دیدیم، فقط در خانواده دیگه. هدف از تفاوت dnf و rpm همینه: بدونی کِی باید درباره پایگاه داده بسته سؤال بپرسی و کِی مدیر مخزن رو وارد کار کنی.

تفاوت rpm -i با dnf install چیه؟

اگر یه فایل RPM روی دیسک داری، عجله نکن که مستقیماً با ابزار سطح پایین نصبش کنی. rpm می‌تونه با بسته محلی کار کنه، اما حل وابستگی‌ها از مخزن معمولاً کار dnf هست. توی آموزش dnf اول ازت می‌خوام منبع فایل و سازگاری با توزیع رو بررسی کنی. این قسمت از مدیریت بسته در لینوکس برای هر دو خانواده یک قاعده داره: بسته ناشناس رو فقط به خاطر اینکه پسوند آشنا داره نصب نکن.

# الگوهای آموزشی؛ فقط روی VM و پس از بررسی بسته و عملیات
sudo dnf install jq
sudo dnf remove jq
sudo dnf upgrade

دستورهایی مثل dnf install، dnf remove و dnf upgrade می‌تونن وضعیت سیستم رو تغییر بدن. قبل از تأیید عملیات، حجم دانلود، وابستگی‌ها، بسته‌های حذف‌شونده و سرویس‌هایی رو که ممکنه تحت تأثیر قرار بگیرن ببین. آموزش rpm و DNF وقتی ارزش داره که بتونی توضیح بدی بعد از اجرای دستور چه چیزی تغییر می‌کنه؛ نه اینکه فقط دستور رو سریع‌تر تایپ کنی.

YUM و Zypper رو چرا باید بشناسیم؟

حالا برسیم به دو اسم دیگه. توی بعضی منابع می‌بینی «آموزش yum» و یه جای دیگه می‌پرسی «zypper چیست؟». ابزار yum توی تاریخ خانواده Red Hat نقش مهمی داشته و روی نسخه‌های جدید ممکنه به سازوکار متفاوتی وصل باشه؛ zypper هم ابزار اصلی مدیریت بسته در openSUSE به حساب میاد. در آموزش LPIC-1 باید هر دو رو بشناسی، چون هدف ۱۰۲.۵ فقط به Fedora محدود نیست. اگر می‌خوای روی هرکدوم آزمایش واقعی انجام بدی، از ماشین مجازی متناسب با همون توزیع استفاده کن.

چرا نصب موفق به معنی اجرای موفق نرم‌افزار نیست؟

گاهی نصب بسته کاملاً موفق گزارش می‌شه، ولی برنامه موقع اجرا خطای کتابخانه یا تنظیمات می‌ده. حتی ممکنه دو نسخه از یک فرمان داشته باشی؛ یکی از مخزن توزیع نصب شده و یکی توی پوشه کاربر قرار گرفته. پس در مدیریت پکیج در لینوکس سه مرحله رو جدا کن: «بسته نصب شده؟»، «کدوم فایل اجرا می‌شه؟» و «برنامه کار مورد انتظار رو انجام می‌ده؟». فقط با جواب سؤال اول نمی‌تونی درباره دو سؤال بعدی مطمئن باشی.

command -v jq || true
type -a jq 2>/dev/null || true
jq --version 2>/dev/null || true

وقتی فرمان پیدا نمی‌شه، بدون بررسی سراغ اضافه‌کردن Repository یا نصب دوباره نرو. اول command -v و type -a رو ببین، بعد وضعیت بسته نصب‌شده رو با ابزار مناسب توزیع بررسی کن. این روش برای رفع خطای نصب پکیج لینوکس هم مفیده: گاهی اصلاً مشکل از نصب نیست و Shell داره مسیر دیگه‌ای رو انتخاب می‌کنه. اگر فرمان اجرا شد ولی نتیجه اشتباه بود، با ورودی مشخص یه آزمایش کوچیک بساز.

آیا هر بسته قدیمی ناامنه؟ فرق نسخه نرم‌افزار با وصله امنیتی

یه سؤال مهم: هر بسته‌ای که شماره نسخه‌اش قدیمیه، الزاماً ناامنه؟ نه. توزیع‌های پایدار گاهی وصله امنیتی رو روی نسخه‌ای اعمال می‌کنن که شماره اصلی برنامه خیلی تغییر نکرده. برای همین موقع مدیریت بسته در دبیان یا اوبونتو نباید فقط شماره نسخه رو با آخرین Release سایت سازنده مقایسه کنی. وضعیت پشتیبانی، اطلاعیه امنیتی توزیع و بسته‌ای که واقعاً نصب شده ملاک‌های بهتری هستن.

از اون طرف، رسمی بودن مخزن هم به معنی نبودن باگ نیست. اما این دلیل نمی‌شه که برای گرفتن نسخه جدید، به هر Repository ناشناسی اعتماد کنی. تصمیم درست در مدیریت پکیج در لینوکس اینه که دلیل تغییر، منبع بسته و راه برگشت رو از قبل مشخص کنی. اگه نسخه فعلی نیازهای برنامه رو برطرف می‌کنه، شاید اصلاً لازم نباشه همین لحظه چیزی عوض کنی.

چرا نباید موقع خطای قفل APT، فایل Lock رو حذف کنیم؟

یکی از خطاهایی که موقع آموزش apt زیاد بهش برمی‌خوری، پیام قفل شدن مدیر بسته‌ست. ممکنه یه آپدیت خودکار یا نصب دیگه هنوز مشغول کار باشه. حذف دستی فایل Lock یا کشتن عجولانه پردازش ممکنه سیستم بسته‌بندی رو وسط عملیات رها کنه. برای رفع خطای نصب پکیج لینوکس اول باید بفهمی چه فرایندی قفل رو نگه داشته و آیا در حال انجام کاره یا واقعاً گیر کرده؛ بعد تصمیم بگیری.

این خطا با مشکل امضای مخزن یا وابستگیِ حل‌نشده یکی نیست. هر سه ممکنه در نهایت باعث نصب نشدن برنامه بشن، ولی علت‌هاشون فرق داره. توی مدیریت پکیج در لینوکس، پیام خطا رو بخون و با وضعیت سیستم تطبیق بده؛ دنبال یه دستور جادویی که همه مشکل‌ها رو با هم حل کنه نگرد.

وقتی Package پیدا نمی‌شه، از کجا باید شروع کنی؟

مثلاً در Ubuntu پیام Unable to locate package دیدی. معنی دقیقش اینه که APT با فهرست فعلی خودش بسته‌ای با این نام پیدا نکرده. شاید اسم اشتباهه، شاید فهرست‌ها قدیمیه یا بسته برای نسخه و معماری تو منتشر نشده. برای رفع خطای نصب پکیج لینوکس، اول نام بسته و مخزن فعال رو بررسی کن؛ تغییر دادن همه Sources بدون فهمیدن علت، کار رو پیچیده‌تر می‌کنه.

روی Fedora هم وقتی dnf بسته‌ای رو پیدا نمی‌کنه، قبل از هر چیز اسم، نسخه توزیع و مخزن‌های فعال رو بررسی کن. بخشی از آموزش dnf همین مهار کردن عجله برای اضافه‌کردن منبع جدیده. چون با اضافه‌کردن Repository ناشناخته شاید مشکل یه بسته حل بشه، اما انتخاب نسخه برای بسته‌های دیگه تغییر کنه و دردسر بزرگ‌تری بسازه.

وقتی نسخه نصب‌شده با Candidate فرق داره، دقیقاً چه نتیجه‌ای می‌گیریم؟

وقتی Installed و Candidate متفاوتن، هنوز نمی‌شه گفت باید فوراً آپدیت کنی. شاید بسته Hold شده، شاید نسخه پیشنهادی از منبع دیگه‌ای میاد یا شاید مدیر سیستم عمداً نسخه رو ثابت نگه داشته. توی مدیریت بسته در اوبونتو با apt-cache policy شروع می‌کنیم و بعد وابستگی‌ها و دلیل اختلاف رو بررسی می‌کنیم. یک شماره نسخه به‌تنهایی داستان کامل رو نمی‌گه.

پس هر بار یه خروجی دیدی، بپرس «این خروجی دقیقاً چی رو ثابت می‌کنه و چی رو نه؟». همین سؤال ساده، فرق عیب‌یابی منطقی با امتحان‌کردن شانسی دستورهاست. هرچی توی مدیریت پکیج در لینوکس جلوتر بری، بیشتر می‌بینی که چند شاهد کوچیک کنار هم از یه فرمان سنگین و عجولانه ارزشمندترن.

تمرین عملی اول : بدون تغییر سیستم، پرونده یک بسته رو بساز

برای تمرین اول روی یه ماشین Debian یا Ubuntu از bash استفاده کن. این بار قرار نیست چیزی نصب یا حذف کنیم. می‌خوایم نسخه نصب‌شده، نسخه قابل انتخاب، مالک فایل اجرایی و نتیجه شبیه‌سازی رو کنار هم ببینیم. این دقیقاً یه تمرین کم‌خطر برای مدیریت بسته در دبیان و آموزش apt هست؛ خروجی‌ها رو بخون و خودت برای هر کدوم یک توضیح بنویس.

cat /etc/os-release | head -8
apt-cache policy bash
dpkg-query -W -f='${binary:Package} ${Version}\n' bash
dpkg-query -S /usr/bin/bash
apt-get -s install bash

بعد از اجرای دستورها، به‌جای اینکه خروجی رو با متن من کلمه‌به‌کلمه مقایسه کنی، این سه سؤال رو جواب بده: bash از نظر DPKG نصبه؟ APT چه نسخه‌ای رو Candidate می‌دونه؟ شبیه‌سازی چه تغییری پیشنهاد می‌کنه؟ ممکنه روی سیستم تو بعضی مسیرها یا شماره نسخه‌ها فرق داشته باشن. این تفاوت اشکال نیست؛ هدف اینه که دلیلش رو از روی شواهد توضیح بدی.

تمرین عملی دوم : تصمیم مدیر بسته رو بدون اجرای واقعی شبیه‌سازی کنیم

حالا برای اینکه موقع تصمیم‌گیری عجله نکنی، یه تمرین مستقل با Python داریم. توی «اتاق تحویل صدا» سه بسته فرضی تعریف می‌کنیم: یکی تغییری لازم نداره، یکی نسخه جدید داره و یکی از منبع ناشناس پیشنهاد شده. قراره بدون اجرای APT یا DNF، فقط منطق تصمیم‌گیری رو تمرین کنیم. این برنامه جای مدیر بسته رو نمی‌گیره، ولی ذهنیت لازم برای مدیریت پکیج در لینوکس رو تقویت می‌کنه.

# save as package_review.py
packages = [
    {"name": "audio-index", "installed": "1.4", "candidate": "1.4", "source": "trusted", "deps_ok": True},
    {"name": "caption-check", "installed": "2.0", "candidate": "2.1", "source": "trusted", "deps_ok": True},
    {"name": "wave-report", "installed": "0.8", "candidate": "1.1", "source": "unknown", "deps_ok": False},
]

for pkg in packages:
    name = pkg["name"]
    if pkg["source"] != "trusted":
        decision = "REVIEW_SOURCE"
    elif not pkg["deps_ok"]:
        decision = "CHECK_DEPENDENCIES"
    elif pkg["installed"] == pkg["candidate"]:
        decision = "NO_CHANGE"
    else:
        decision = "REVIEW_UPGRADE"
    print(f"{name}: {decision}")

audio-index: NO_CHANGE
caption-check: REVIEW_UPGRADE
wave-report: REVIEW_SOURCE

اگر کد رو همون‌طور که نوشته شده اجرا کنی، باید سه برچسب NO_CHANGE، REVIEW_UPGRADE و REVIEW_SOURCE رو ببینی. اینجا فقط برابری رشته نسخه‌ها بررسی می‌شه؛ برنامه ما نسخه‌بندی واقعی Debian یا RPM رو تحلیل نمی‌کنه و وابستگی‌ها رو هم حل نمی‌کنه. پس نتیجه‌اش یک تمرین آموزشیه، نه پیشنهاد نصب واقعی. عمداً ساده نگهش داشتیم تا قبل از انتخاب دستور، منطق تصمیم رو ببینی.

پنج اشتباه پرتکرار که موقع نصب برنامه در لینوکس دردسر درست می‌کنن

اشتباه اول : هر چیزی پیدا شد، با sudo اجراش کنیم

وقتی توی یه سایت دستور curl ... | bash می‌بینی، مخصوصاً با sudo، نباید بدون بررسی اجراش کنی. داری کدی رو با دسترسی بالا اجرا می‌کنی که شاید حتی ندونی از کجا اومده. توی آموزش نصب نرم افزار در لینوکس همیشه منبع رسمی توزیع و راه اعتبارسنجی فایل رو در اولویت بذار؛ نصب موفق به‌تنهایی امنیت رو ثابت نمی‌کنه.

اشتباه دوم : برای یک برنامه، چند منبع ناسازگار رو قاطی کنیم

گاهی یه بسته توی نسخه توزیع تو نیست و وسوسه می‌شی Repository مربوط به نسخه دیگه Debian یا Ubuntu رو اضافه کنی. این کار ممکنه کتابخانه‌ها و بسته‌های پایه رو هم به سمت نسخه ناسازگار ببره. موقع مدیریت بسته در دبیان یا اوبونتو، اگه بسته‌ای در دسترس نیست، اول راه‌حل‌های پشتیبانی‌شده مثل مخزن معتبر متناسب با نسخه، Backport یا محیط جدا رو بررسی کن.

اشتباه سوم : خطای وابستگی رو با Force درمان کنیم

وقتی یه نصب به خطای وابستگی می‌خوره، گزینه‌های Force جواب جادویی نیستن. ممکنه نصب ناقص بمونه یا وضعیت فایل‌ها با پایگاه داده بسته‌ها هماهنگ نباشه. برای رفع خطای نصب پکیج لینوکس اول دقیق مشخص کن کدوم وابستگی، چه نسخه‌ای و از چه منبعی لازم شده. بعد با ابزار استاندارد توزیع، نه با دستورهای شانسی، راه‌حل رو پیدا کن.

اشتباه چهارم : قبل از remove یا autoremove لیست رو نخونیم

قبل از remove یا autoremove به لیست حذف نگاه کن. مدیر بسته وابستگی‌ها رو حساب می‌کنه، ولی نمی‌دونه روی سرور تو ممکنه یه برنامه به فایلی وابسته باشه که خارج از سیستم بسته‌بندی مدیریت می‌شه. توی مدیریت پکیج در لینوکس حذف کردن هم به اندازه نصب کردن نیاز به بررسی داره؛ مخصوصاً وقتی سرویس فعال روی همون ماشین داری.

اشتباه پنجم : آپدیت برنامه رو با آپدیت کل سیستم یکی بدونیم

گاهی فقط یه ابزار به نسخه جدیدتر نیاز داره، ولی دستور آپدیت کل سیستم رو اجرا می‌کنی و چندین پکیج دیگه هم تغییر می‌کنن. قبل از ارتقا، دقیق ببین محدوده عملیات چیه. توی آموزش apt و DNF قرار نیست هر مسئله کوچیک رو با آپدیت همه‌چیز جواب بدیم. تغییر محدود و قابل بررسی معمولاً عیب‌یابی بعدی رو هم ساده‌تر می‌کنه.

چطور مدیریت پکیج رو به عیب‌یابی سرویس‌های لینوکس وصل کنیم؟

فرض کن بعد از آپدیت یه بسته، سرویس مرتبط باهاش خطا می‌ده. اینجا دو مسیر داریم: مدیر بسته چه چیزی تغییر داده و خود سرویس چه خطایی ثبت می‌کنه؟ برای مسیر دوم می‌تونی به درس عیب‌یابی سرویس‌ها با systemctl برگردی. ارتباط این دو درس مهمه؛ مدیریت پکیج در لینوکس درباره نسخه و نصب صحبت می‌کنه، اما بررسی سلامت سرویس به شواهد زمان اجرا هم احتیاج داره.

اول زمان تغییر، نسخه قبلی و جدید، منبع بسته، وضعیت سرویس و لاگ‌ها رو کنار هم بذار. بعد تصمیم بگیر مشکل از تنظیماته، از وابستگیه یا از خود نسخه جدید. این روش هم برای مدیریت بسته در لینوکس به درد می‌خوره، هم برای کارهای DevOps و مدیریت سرور. چیزی که می‌خوام یاد بگیری اینه: قبل از برگردوندن نسخه یا ری‌استارت کردن، علت رو پیدا کن.

برای LPIC-1 دقیقاً چه چیزهایی از این درس باید بلد باشی؟

برای آموزش LPIC-1 باید بدونی مبحث ۱۰۲.۴ روی نصب، حذف، اطلاعات نسخه و وابستگی‌های بسته در Debian تمرکز داره. در ۱۰۲.۵ هم باید RPM، YUM و Zypper رو بشناسی و با DNF آشنا باشی. این مقاله همه سرفصل‌های آزمون رو پوشش نمی‌ده، ولی یه مسیر عملی برای Linux Package Management می‌ده: اول ابزار مناسب رو انتخاب کن، بعد اطلاعات بسته رو بخون و در نهایت نتیجه عملیات رو بسنج.

اگر هنوز با مسیر فایل‌ها و کار در ترمینال راحت نیستی، قبل از ادامه می‌تونی درس ترمینال لینوکس و درس دستورات کاربردی رو مرور کنی. چون برای اینکه آموزش rpm، dpkg یا apt واقعاً برات کاربردی بشه، باید بتونی خروجی یک فرمان و مسیر فایل اجرایی رو درست بخونی.

تمرین پایانی : خودت مثل یک مدیر لینوکس تصمیم بگیر

حالا نقش مدیر ماشین Ubuntu رو بازی کن. نسخه نصب‌شده jq با Candidate فرق داره و یک فایل اجرایی هم از مسیر نامعلوم پیدا شده. قبل از هر تغییری با apt-cache policy منبع نسخه پیشنهادی رو ببین، با dpkg-query -S مالک فایل رو بررسی کن و با command -v مسیر اجرای دستور رو پیدا کن. بعد بنویس این سه شاهد چه چیزهایی رو درباره مدیریت بسته در اوبونتو روشن می‌کنن و کجا هنوز سؤال داریم.

حالا برو سراغ Fedora فرضی. dnf info درباره نسخه بسته یه چیز می‌گه، اما خروجی jq --version با انتظار تو فرق داره. اول مسیر واقعی فرمان و وضعیت بسته نصب‌شده رو بررسی کن؛ بعد بپرس آیا چند نسخه یا چند منبع مختلف وجود داره. این تمرین هم آموزش dnf هست، هم نشون می‌ده چرا تفاوت dnf و rpm رو باید در عمل بفهمی؛ عجله برای نصب دوباره، تشخیص نیست.

جمع‌بندی : حرفه‌ای بودن یعنی قبل از Enter بدونی چی قراره عوض بشه

اگه بخوام این درس رو جمع کنم، می‌گم مدیریت پکیج در لینوکس یعنی قبل از Enter بدونی چه چیزی نصبه، از کجا اومده و قراره چی تغییر کنه. حالا هم تفاوت apt و dpkg رو دیدی، هم فهمیدی DNF و RPM نقش یکسانی ندارن، هم یاد گرفتی بین «بسته نصب شد» و «برنامه درست کار می‌کنه» فاصله هست. این مدل فکر کردن رو توی هر توزیعی با خودت ببر؛ از خودِ حفظ دستورها مهم‌تره.

اگه دلت می‌خواد مدیریت بسته در لینوکس رو کنار بوت، سرویس‌ها، دیسک و عیب‌یابی، با تمرین‌های منسجم‌تری ادامه بدی، می‌تونی صفحه دوره کامل LPIC-1 نابغه‌ها رو ببینی. این درس رایگان برای فهمیدن منطق نصب و مدیریت بسته بود؛ دوره مسیر کامل‌تری برای تمرین بقیه مهارت‌های مدیریت لینوکس در اختیارت می‌ذاره.

سؤالات متداول مدیریت پکیج در لینوکس

منابع رسمی برای مطالعه بیشتر

برای اینکه جزئیات رو خودت هم چک کنی، از اهداف رسمی LPIC-1، راهنمای مدیریت بسته Debian، مستندات APT، مستندات DNF و راهنمای Debian درباره مخزن‌های ناسازگار کمک بگیر. تمرین «اتاق تحویل صدا» صرفاً یه سناریوی آموزشی فرضیه؛ رفتار نسخه‌های مختلف ابزارها رو بهتره همیشه با مستندات همون سیستم تطبیق بدی.