ZYPP.CONF(5) LIBZYPP File Formats Manual ZYPP.CONF(5)

zypp.conf - فایل پیکربندی کتابخانه مدیریت بسته ZYpp

فایل‌های پیکربندی سیستم: /etc/zypp/zypp.conf /etc/zypp/zypp.conf.d/*.conf.
فایل‌های پیکربندی ارائه‌دهنده: /usr/etc/zypp/zypp.conf /usr/etc/zypp/zypp.conf.d/*.conf.

این فایل‌ها حاوی داده‌های پیکربندی پایه برای libzypp هستند؛ کتابخانه مدیریت بسته‌ای که توسط فرآیندهایی نظیر zypper(8)، YAST(8) یا پس‌دستانه zypp در PackageKit استفاده می‌شود. بسیاری از مقادیر پیکربندی می‌توانند توسط فرآیندها بر اساس گزینه‌های خط فرمان یا سایر نیازها اصلاح شوند. در غیر این صورت، مقادیر تعریف‌شده در اینجا به عنوان پیش‌فرض استفاده می‌شوند. هنگامی که این فایل‌ها پارامتر خاصی را مشخص نکنند، مقادیر پیش‌فرض توکار libzypp به کار گرفته می‌شوند.

قالب این فایل از بخش‌های چندگانه پشتیبانی می‌کند که هر یک می‌توانند شامل چندین انتساب کلید-مقدار باشند. هر بخش با خطی شامل نام بخش درون براکت‌ها معرفی می‌شود، مانند:
         [name]
یک انتساب کلید-مقدار یک خط منفرد است که شامل نام کلید، یک علامت مساوی و تنظیمی برای مقدار است، مانند:
         key = value
فاصله‌های خالی ابتدا و انتهای خط و فاصله‌های اطراف علامت مساوی نادیده گرفته می‌شوند.

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

جستجوی نام بخش‌ها و کلیدها به حروف بزرگ و کوچک حساس است.

هر خطی که با # شروع شود و همچنین هر خط خالی نادیده گرفته می‌شود.

در جایی که یک مقدار بولی مورد انتظار باشد، می‌توان از هر یک از مقادیر 1، 0، yes، no، on، off، true یا false استفاده کرد. مقایسه‌ها در اینجا به حروف بزرگ و کوچک حساس نیستند.

برای یادگیری نحوه ادغام فایل‌های پیکربندی مختلف، بخش فایل‌ها (FILES) را ببینید. توصیه ما نگهداری پیکربندی سیستم با استفاده از فایل‌های تکمیلی (drop-in) در /etc/zypp/zypp.conf.d/ است، به جای آنکه پیکربندی ارائه‌دهنده را با یک فایل اختصاصی /etc/zypp/zypp.conf بازنویسی کنید؛ هرچند هر دو روش امکان‌پذیر است. فقط اطمینان حاصل کنید که /etc/zypp/zypp.conf شما شامل تنظیمات مناسبی برای کلیدهای تعریف‌شده در /usr/etc/zypp/zypp.conf باشد. در زمان نگارش این سند، این کلیدها تنها شامل multiversion و multiversion.kernels هستند.

بخش‌های زیر شناخته‌شده هستند و می‌توانند شامل انتساب‌های کلید مشخص‌شده باشند. مقدار پیش‌فرض توکار libzypp برای هر کلید در پرانتز آورده شده است، مانند:
         key (value)
برای برخی کلیدها مقدار پیش‌فرض توکار ثابتی وجود ندارد، بلکه بهترین مقدار با توجه به کار مشخصی که باید انجام شود انتخاب می‌شود. در حالی که تعیین یک مقدار ثابت ممکن است، اغلب بهترین تصمیم این است که این کلید را اصلاً تعریف نکنید. این موضوع با نمایش <UNSET> به عنوان مقدار پیش‌فرض نشان داده شده است، مانند:
         key (<UNSET>)
بسیاری از مقادیر پیش‌فرض تعیین‌شده در اینجا را می‌توان از طریق گزینه‌های خط فرمان zypper لغو کرد. این موضوع به ویژه برای پیش‌فرض‌های مربوط به حل‌کننده وابستگی (resolver) صادق است. برای جزئیات بیشتر به صفحه راهنمای zypper(8) مراجعه کنید.

lock_timeout (0 sec)

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

می‌توان از متغیر محیطی ZYPP_LOCK_TIMEOUT برای لغو این تنظیم استفاده کرد. مقدار ZYPP_LOCK_TIMEOUT=-1 گاهی توسط اسکریپت‌هایی که بدون نظارت اجرا می‌شوند تنظیم می‌شود تا در صورت در دسترس نبودن قفل، به جای شکست دستور zypper، اجرای آن را به تعویق بیندازد.

cachedir (/var/cache/zypp)

مسیری که حافظه‌های موقت (کش‌ها) در آن نگهداری می‌شوند.

metadatadir ({cachedir}/raw)

مسیری که فراداده‌های دانلودشده مخزن در آن نگهداری می‌شوند.

solvfilesdir ({cachedir}/solv)

مسیری که کش‌های فایل .solv مخزن در آن نگهداری می‌شوند.

packagesdir ({cachedir}/packages)

مسیری که بسته‌های دانلودشده در آن نگهداری می‌شوند.

configdir (/etc/zypp)

مسیری که سایر فایل‌های پیکربندی در آن نگهداری می‌شوند.

reposdir ({configdir}/repos.d)

مسیری که فایل‌های .repo مربوط به مخازن شناخته‌شده در آن نگهداری می‌شوند.

servicesdir ({configdir}/services.d)

مسیری که فایل‌های .service مربوط به سرویس‌های شناخته‌شده در آن نگهداری می‌شوند.

varsdir ({configdir}/vars.d)

مسیری که تعاریف متغیرهای سفارشی مخزن در آن نگهداری می‌شوند.

یک متغیر سفارشی مخزن با ایجاد فایلی در داخل پوشه varsdir تعریف می‌شود. نام متغیر برابر با نام فایل است. خط اول فایل (تا قبل از نویسه خط جدید) مقدار متغیر را تعیین می‌کند. برای جزئیات بیشتر بخش Variable substitution را در صفحه راهنمای zypper(8) ببینید.

vendordir ({configdir}/vendors.d)

مسیری که فایل‌های توصیف هم‌ارزی ارائه‌دهنده (vendor) در آن نگهداری می‌شوند.

هر فایل در این پوشه، فهرستی با کاما جداشده از پیشوندهای رشته‌ای ارائه‌دهندگان هم‌ارز را تعریف می‌کند (مقایسه غیرحساس به حروف بزرگ و کوچک):

-------------------- file begin ----------------
[main]
vendors = MyVendor,AlternateName
-------------------- file end ------------------

با این کار، رشته‌های ارائه‌دهنده‌ای که با «MyVendor» یا «AlternateName» آغاز می‌شوند، هم‌ارز در نظر گرفته می‌شوند. بسته‌های ارائه‌دهندگان هم‌ارز می‌توانند بدون آنکه به عنوان تغییر ارائه‌دهنده (vendor change) در نظر گرفته شوند، جایگزین یکدیگر گردند.

نکته: درون فضای نام «*opensuse» تطابق‌های دقیق (بدون حساسیت به حروف بزرگ و کوچک) الزامی است. مقدار «vendors = suse,opensuse» جابجایی بین «*suse» و «opensuse» را مجاز می‌شمارد، اما برای نمونه «opensuse build service» مجاز نخواهد بود.

repo.add.probe (false)

آیا آدرس‌های اینترنتی مخزن در زمان افزودن (مثلاً از طریق zypper addrepo) باید بررسی شوند یا خیر. اگر false باشد، نشانی مخزن در اولین تازه‌سازی بررسی می‌شود.

repo.refresh.delay (10 min)

مدت زمان بر حسب دقیقه که باید پیش از اقدام مجدد برای تازه‌سازی خودکار مخزن سپری شود.

مقدار 0 یعنی مخزن همیشه بررسی خواهد شد. برای دستیابی به نتیجه معکوس، گزینه autorefresh را برای مخزن غیرفعال کنید. این گزینه هیچ تأثیری روی درخواست‌های تازه‌سازی صریحاً ارسال‌شده توسط کاربر ندارد.

repo.refresh.locales (en)

فهرستی از محلی‌سازی‌ها (locales) که در صورت در دسترس بودن و پشتیبانی مخزن، توضیحات ترجمه‌شده بسته باید برای آن‌ها دانلود شود. همه قالب‌های مخزن از دانلود ترجمه‌های خاص پشتیبانی نمی‌کنند.

فهرست نهایی در عمل از طریق دستورات locales، addlocale و removelocale در zypper کنترل می‌شود. محلی‌سازی‌های تعریف‌شده در اینجا صرفاً ماندگار (sticky) هستند.

download.max_concurrent_connections (5)

حداکثر تعداد اتصالات همزمان مورد استفاده در هر انتقال داده.

download.min_download_speed (0 B/sec)

حداقل سرعت دانلود (به بایت بر ثانیه) را تعیین می‌کند که در صورت افت سرعت به کمتر از آن، اتصال قطع خواهد شد. مقدار 0 به معنای نبود محدودیت است.

این گزینه می‌تواند برای جلوگیری از حملات امنیتی به میزبان‌ها از طریق ارائه به‌روزرسانی‌ها با سرعت بسیار کم مفید باشد.

download.max_download_speed (0 B/sec)

حداکثر سرعت دانلود را تعیین می‌کند (به بایت بر ثانیه). مقدار 0 به معنای نبود محدودیت است.

download.max_silent_tries (1)

[هشدار!] تعداد دفعات تلاش داخلی پس‌دستانه رسانه برای دانلود یک فایل از سرور پیش از گزارش خطا به برنامه در صورت شکست. تنظیم این مقدار روی 0 تلاش مجدد را به طور بی‌صدا تا ابد ادامه خواهد داد! این گزینه عمدتاً در برخی محیط‌های تست و CI استفاده می‌شود اما در دنیای واقعی کاربرد چندانی ندارد.

download.connect_timeout (60 sec)

حداکثر زمان به ثانیه که به مرحله اتصال به سرور اجازه داده می‌شود طول بکشد. این مهلت زمانی فقط مرحله اتصال را محدود می‌کند و پس از برقراری اتصال توسط libcurl دیگر تأثیری ندارد.

download.transfer_timeout (180 sec)

حداکثر زمان به ثانیه که به یک عملیات انتقال داده اجازه داده می‌شود طول بکشد. این گزینه برای جلوگیری از معلق ماندن کارهای دسته‌ای (batch jobs) به مدت چند ساعت به دلیل کندی شبکه یا قطع پیوندها مفید است. محدود کردن عملیات به کمتر از چند دقیقه خطر توقف زودهنگام عملیات‌های کاملاً عادی را به همراه دارد.

download.use_deltarpm (false) (true on SUSE-15.6 and older)

[قدیمی!] اینکه آیا هنگام دانلود بسته، استفاده از .delta.rpm در نظر گرفته شود یا خیر. اگر سرعت اتصال شبکه شما خیلی کند نیست، ممکن است در سوزه 15.6 و نسخه‌های قدیمی‌تر از غیرفعال کردن صریح استفاده از .delta.rpm سود ببرید. توزیع‌های جدیدتر دیگر اصلاً بسته‌های .delta.rpm ارائه نمی‌دهند، بنابراین مقدار پیش‌فرض تغییر یافته تا از بار پردازشی اضافی جلوگیری شود.

download.use_deltarpm.always (false)

[قدیمی!] اینکه آیا حتی در صورت در دسترس بودن فایل کامل .rpm به صورت محلی، باز هم استفاده از .delta.rpm در نظر گرفته شود. این گزینه هیچ تأثیری ندارد مگر اینکه download.use_deltarpm روی true تنظیم شده باشد. فقط برای آزمایش استفاده می‌شود.

download.media_preference (download)

راهنمایی برای اینکه هنگام نصب بسته‌ها کدام رسانه ترجیح داده شود (download در برابر volatile یا همان CD/DVD).

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

بسته‌هایی که به صورت محلی موجود هستند همیشه ترجیح داده می‌شوند. پرسش این است که اگر بسته‌ها روی هر دو رسانه موجود باشند، آیا ترجیح می‌دهید بسته‌ها از طریق FTP/HTTP/HTTPS دانلود شوند (download)، یا اینکه از شما خواسته شود یک CD/DVD را وارد کنید (volatile).

download.media_mountdir (/var/adm/mount)

مسیری که رسانه‌ها ترجیحاً در آن سوار (mount) یا دانلود می‌شوند.

پس‌دستانه رسانه تلاش خواهد کرد نقاط اتصال و نواحی دانلود رسانه را در زیر این پوشه سازماندهی کند، مگر اینکه مکان دیگری توسط برنامه درخواست شده باشد. اگر این پوشه برای یک کاربر خاص قابل دسترسی و خواندن/نوشتن نباشد، حالت جایگزین استفاده از /var/tmp است.

download.use_geoip_mirror (true)

آیا از ویژگی geoip در download.opensuse.org استفاده شود یا خیر.

پس‌دستانه رسانه ممکن است درخواست‌های دانلود را به نزدیک‌ترین آینه (mirror) در دسترس از نظر جغرافیایی بازنویسی کند. آینه دقیق مورد استفاده با درخواست یک فایل «geoip» از download.opensuse.org از طریق درخواست HTTP GET به https://download.opensuse.org/geoip تعیین می‌شود و سرور در صورت امکان از IP کلاینت برای تعیین نزدیک‌ترین آینه استفاده خواهد کرد.

با این حال، برخی فایل‌های خاص به دلایل امنیتی از این تغییر مسیر مستثنی شده‌اند، به ویژه نمایه فراداده‌های مخزن و فایل‌های کلید و چکسام آن: repomd.xml{,.key,.asc}.

gpgcheck (on)

repo_gpgcheck (<UNSET>, depending on {gpgcheck})
pkg_gpgcheck (<UNSET>, depending on {gpgcheck})

بررسی پیش‌فرض امضای فراداده‌های مخزن و بسته‌های rpm دانلودشده.

نکته: تنظیم صریح gpgcheck، repo_gpgcheck و/یا pkg_gpgcheck در فایل .repo یک مخزن، این پیش‌فرض‌ها را برای آن مخزن خاص بازنویسی خواهد کرد. دستورات zypper addrepo و modifyrepo چندین گزینه مربوط به gpgcheck را برای تنظیم دقیق این رفتار فراهم می‌کنند. برای جزئیات به صفحه راهنمای zypper(8) مراجعه کنید.

اگر gpgcheck روی on باشد (پیش‌فرض توصیه‌شده)، امضای فراداده‌های مخزن را بررسی خواهیم کرد. استفاده از مخازن بدون امضا نیازمند تأیید است.

بسته‌های مخازن امضاشده در صورتی پذیرفته می‌شوند که چکسام آن‌ها با چکسام ذکرشده در فراداده‌های مخزن مطابقت داشته باشد.

بسته‌های مخازن بدون امضا نیازمند یک امضای gpg معتبر هستند. استفاده از بسته‌های بدون امضا نیازمند تأیید است.

رفتار پیش‌فرض فوق را می‌توان با تنظیم صریح repo_gpgcheck و/یا pkg_gpgcheck سفارشی کرد. اما به طور کلی توصیه می‌شود که تنظیمات را برای هر مخزن به صورت جداگانه تسهیل کنید، تا اینکه پیش‌فرض‌های سراسری را کاهش دهید:

مقدار repo_gpgcheck = on همانند رفتار پیش‌فرض است.

مقدار repo_gpgcheck = off مخازن بدون امضا را بدون هشدار می‌پذیرد. این کار بررسی امضا را به طور کلی غیرفعال نمی‌کند. با این حال، تنظیم امنی نیست.

مقدار pkg_gpgcheck = on بررسی امضای بسته و نیاز به تأیید بسته‌های بدون امضا را برای همه مخازن (امضاشده و بدون امضا) اجباری می‌کند.

مقدار pkg_gpgcheck = off بسته‌های بدون امضا را بدون هشدار می‌پذیرد. این کار بررسی امضا را به طور کلی غیرفعال نمی‌کند. با این حال، تنظیم امنی نیست.

اگر gpgCheck روی off باشد (توصیه نمی‌شود)، هیچ بررسی انجام نخواهد شد. همچنان می‌توانید آن‌ها را به صورت جداگانه با تنظیم repo_gpgcheck و/یا pkg_gpgcheck روی on فعال کنید.

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

commit.downloadMode (<UNSET>)

سیاست پیش‌فرض دانلود بسته‌ها هنگام اعمال تغییرات (commit). اگر مقدار تنظیم نشده، خالی یا ناشناخته باشد، بسته به وظیفه‌ای که قرار است انجام شود یک مقدار پیش‌فرض معقول انتخاب می‌کنیم. به ندرت نیازی به تنظیم یک پیش‌فرض ثابت در اینجا وجود دارد.

DownloadInAdvance: ابتدا همه بسته‌ها در کش محلی دانلود می‌شوند؛ سپس نصب آغاز می‌شود. این روش، پیش‌فرض امن و ترجیح‌داده‌شده هنگام نصب بسته‌ها روی سیستم محلی است.

DownloadInHeaps: مشابه DownloadInAdvance است، اما تلاش می‌کند تراکنش را به دسته‌هایی تقسیم کند که در پایان هر دسته، سیستم به یک وضعیت پایدار و یکپارچه برسد.

DownloadAsNeeded: دانلود و نصب به صورت متناوب. بسته‌ها صرفاً برای جلوگیری از تعویض مکرر CD/DVD کش می‌شوند. این حالت در فضای دیسک صرفه‌جویی می‌کند اما در صورتی که بسته‌ای در میانه تراکنش دریافت نشود، مستعد خطا است. این گزینه برای نصب در chroot مناسب است، اما برای سیستم محلی کاربرد ندارد.

solver.focus (<UNSET>)

رویکرد کلی حل‌کننده هنگام حل وظایف. اگر مقدار تنظیم نشده، خالی یا ناشناخته باشد، از پیش‌فرض حل‌کننده استفاده می‌کنیم.

Job: تمرکز بر نصب بهترین نسخه از بسته‌های درخواستی. وابستگی‌های ناموجود در صورت نیاز اضافه می‌شوند. این پیش‌فرض حل‌کننده است.

Installed: تمرکز بر اعمال کمترین تغییرات ممکن در بسته‌های نصب‌شده. انتخاب نسخه قدیمی‌تر یک بسته در صورتی مجاز است که وابستگی‌های آن نیازمند تغییرات کمتری در سیستم باشند.

Update: تمرکز بر به‌روزرسانی بسته‌های درخواستی و وابستگی‌های آن‌ها تا حد امکان.

solver.onlyRequires (false)

آیا حل‌کننده فقط باید بسته‌های الزامی را انتخاب کند یا خیر. در غیر این صورت، بسته‌های توصیه‌شده (recommended) نیز در نظر گرفته می‌شوند.

solver.allowVendorChange (false)

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

solver.dupAllowDowngrade (true)
solver.dupAllowNameChange (true)
solver.dupAllowArchChange (true)
solver.dupAllowVendorChange (false)

[فقط برای کاربران حرفه‌ای!] کار ارتقای توزیع (dup) حل‌کننده از پیش‌فرض‌های متفاوتی در مقایسه با کارهای عادی نصب و به‌روزرسانی برای تنزل نسخه، تغییر نام، تغییر معماری و محافظت از ارائه‌دهنده استفاده می‌کند. تغییر دادن این پیش‌فرض‌ها بدون نیاز واقعی توصیه نمی‌شود. در صورت تردید، zypper(8) گزینه‌های خط فرمانی را فراهم می‌کند تا این تغییرات را فقط برای یک کار خاص اعمال کنید.

solver.cleandepsOnRemove (false)

[فقط برای کاربران حرفه‌ای!] پاک‌سازی هنگام حذف بسته‌ها. اینکه آیا حل‌کننده باید به طور پیش‌فرض تلاش کند بسته‌هایی را که منحصراً توسط بسته‌های در حال حذف درخواست شده بودند، حذف کند یا خیر.

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

solver.noUpdateProvide (false)

[فقط برای کاربران حرفه‌ای!] به طور کلی، بسته‌هایی که بسته دیگری را منسوخ می‌کنند به عنوان گزینه‌های به‌روزرسانی برای بسته منسوخ‌شده در نظر گرفته می‌شوند. با این حال، قوانین به‌روزرسانی ویژه سوزه گزینه‌هایی را ترجیح می‌دهند که صریحاً بسته منسوخ‌شده را نیز فراهم (provide) کنند.

گاهی غیرفعال کردن این قانون ضروری یا مفید است.

solver.checkSystemFile (/etc/zypp/systemCheck)

این فایل شامل نیازمندی‌ها و تعارض‌هایی است که نیازهای یک سیستم در حال اجرا را برآورده می‌سازند. برای مثال اگر هیچ glibc یا kernel نصب نشده باشد، سیستم آسیب می‌بیند. حل‌کننده همیشه از این محدودیت‌ها آگاه است و دقت می‌کند که نقض نشوند.

هر خط در فایل نشان‌دهنده یک وابستگی است: requires:kernel یا requires:glibc.

solver.checkSystemFileDir ({configdir}/systemCheck.d)

مسیری که می‌توان فایل‌های تکمیلی checkSystem را در آن قرار داد. فایل‌ها به ترتیب الفبایی نام فایل‌ها خوانده می‌شوند. solver.checkSystemFile را ببینید.

solver.upgradeTestcasesToKeep (2)

هنگام ثبت ارتقای توزیع (مثلاً با zypper dup)، یک نمونه آزمایشی حل‌کننده در /var/log/updateTestcase-<date> نوشته می‌شود. این نمونه آزمایشی اغلب در گزارش‌های اشکال مربوط به مهاجرت یا ارتقای توزیع درخواست می‌شود. این گزینه تعداد نمونه‌های آزمایشی را که باید روی سیستم نگهداری شوند تعیین می‌کند. با ایجاد نمونه‌های جدید، نمونه‌های قدیمی حذف می‌شوند. برای ننوشتن هیچ نمونه آزمایشی از 0، یا برای نگه‌داشتن تمام نمونه‌های آزمایشی از -1 استفاده کنید.

solver.upgradeRemoveDroppedPackages (true)

آیا ارتقای توزیع باید بسته‌های کنارگذاشته‌شده (dropped) یک محصول را حذف کند یا خیر.

یک محصول جدید ممکن است فهرستی از بسته‌های قدیمی و بدون پشتیبانی را پیشنهاد دهد (بسته‌های کنارگذاشته‌شده). هنگام انجام ارتقای توزیع، حل‌کننده ممکن است تلاش کند آن‌ها را حذف کند، حتی اگر هیچ مشکل وابستگی ایجاد نکنند.

همچنین zypper dup --remove-orphaned را ببینید که نوع مشابهی از پاک‌سازی را فراهم می‌کند. این دستور بسته‌هایی را که دیگر مورد نیاز نیستند و دیگر توسط هیچ مخزن فعالی ارائه نمی‌شوند (به اصطلاح بسته‌های یتیم یا orphaned) پاک‌سازی می‌کند.

multiversion (<EMPTY>) [provides:multiversion(kernel) via vendor configuration]

فهرستی جداشده با کاما از بسته‌هایی که به گونه‌ای ساخته شده‌اند که بتوانند و باید در چندین نسخه مختلف به صورت همزمان نصب شوند.

بسته‌ها بر اساس نام یا بر اساس قابلیت‌های فراهم‌شده (provides) انتخاب می‌شوند. در حالت دوم، رشته باید با «:provides» آغاز شده و بلافاصله قابلیت مربوطه پس از آن بیاید.

[هشدار!] در حالی که حذف تعریف در اینجا ایمن است (که در این صورت با هسته مانند سایر بسته‌ها رفتار خواهد شد)، هنگام افزودن تعاریف جدید بسیار مراقب باشید. اگر بسته‌هایی را اضافه کنید که برای پشتیبانی از نصب در چندین نسخه ساخته نشده‌اند، به سادگی به یکدیگر آسیب خواهند زد.

multiversiondir ({configdir}/multiversion.d)

مسیری که می‌توان فایل‌های تکمیلی multiversion را در آن قرار داد. فایل‌ها به ترتیب الفبایی نام‌هایشان خوانده می‌شوند. multiversion را ببینید.

multiversion.kernels (<EMPTY>) [latest,latest-1,running via vendor configuration]

فهرستی جداشده با کاما از بسته‌های هسته که در صورت فراخوانی zypper purge-kernels و تنظیم multiversion برای بسته‌های هسته، باید در سیستم نگهداری شوند. بسته‌های هسته را می‌توان به صورت‌های زیر مشخص کرد:
2.6.32.12-0.7 - نسخه دقیق هسته برای نگهداری
latest - نگهداری هسته با بالاترین شماره نسخه
latest-N - نگهداری هسته با Nمین بالاترین شماره نسخه
running - نگهداری هسته در حال اجرا
oldest - نگهداری هسته با کمترین شماره نسخه
oldest+N - نگهداری هسته با Nمین کمترین شماره نسخه

اگر هیچ مقداری مشخص نشود، هیچ هسته‌ای پاکسازی نخواهد شد.

locksfile.path ({configdir}/locks)

فایلی که قفل‌های اعمال‌شده روی بسته‌ها را نگهداری می‌کند. برای جزئیات بیشتر به دستورات locks، addlock و removelock در zypper(8) مراجعه کنید.

locksfile.apply (true)

آیا قفل‌های ذخیره‌شده در فایل locksfile در زمان راه‌اندازی اعمال شوند یا خیر.

update.messages.notify (<EMPTY>)

بسته‌ها پس از نصب ممکن است یک فایل پیام به‌روزرسانی در /var/adm/update-messages بر جای بگذارند. در پایان هر تعهد (commit)، zypp ممکن است این پیام‌ها را جمع‌آوری کرده و اعلانی را برای کاربر ارسال کند.

zypp پیام‌های به‌روزرسانی را بر اساس قالب محتوای انتخاب‌شده آماده کرده و محتوا را به دستور مشخص‌شده ارسال (pipe) می‌کند.

قالب:

single - برای هر پیام به‌روزرسانی دستور را فراخوانی کرده و پیام را ارسال می‌کند.
none - برای هر پیام به‌روزرسانی دستور را فراخوانی می‌کند اما از لوله (pipe) برای ارسال داده استفاده نمی‌کند. احتمالاً می‌خواهید فایل پیام را در خط فرمان با استفاده از %P ارسال کنید (بخش جایگزینی‌ها را در زیر ببینید).
digest - فراخوانی تکی دستور، با ارسال نام مسیر تمامی پیام‌های به‌روزرسانی، یک مورد در هر خط.
bulk - فراخوانی تکی دستور، با ارسال محتوای الحاق‌شده تمامی پیام‌های به‌روزرسانی که با Ctrl-L جدا شده‌اند.

جایگزینی‌ها:

%p - مشخصه بسته (Name-Version-Release.Arch_)
%P - مسیر کامل فایل پیام به‌روزرسانی

مقادیر معتبر:

مقدار به صورت قالب | دستور مشخص می‌شود. یک مقدار خالی هرگونه اعلان را غیرفعال خواهد کرد.

مثال‌ها:

single | mail -s "Update message from %p" root
none | my-send-script -f %P

rpm.install.excludedocs (false)

فایل‌هایی را که به عنوان مستندات علامت‌گذاری شده‌اند نصب نکن. برای جزئیات به گزینه --excludedocs در rpm(8) مراجعه کنید.

این گزینه اغلب هنگام ساخت تصاویر کانتینر برای صرفه‌جویی در فضای دیسک استفاده می‌شود.

history.logfile (/var/log/zypp/history)

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

credentials.global.dir ({configdir}/credentials.d)

مسیر پوشه سراسری اطلاعات کاربری و احراز هویت.

اگر یک URL دارای پارامتر ?credentials=<filename> باشد، اطلاعات احراز هویت در فایلی به نام <filename> در این پوشه ذخیره شده و جستجو می‌شود.

credentials.global.file ({configdir}/credentials.cat)

مسیر فایل کاتالوگ سراسری اطلاعات کاربری و احراز هویت.

این فایل می‌تواند شامل کاتالوگی از اطلاعات کاربری باشد که از طریق پارامتر ?credentials=<filename> ذخیره نشده‌اند (credentials.global.dir را ببینید).

این فایل در صورت وجود خوانده می‌شود، اما اطلاعات کاربری جدید معمولاً در پوشه خانگی کاربر ذخیره می‌شوند (~/.zypp/credentials.cat).

arch (<UNSET>)

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

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

دستور key = value تلاش می‌کند متغیر محیطی با نام key را به مقدار value تنظیم کند.

این ویژگی برای فراهم آوردن تنظیمات خاص محیط یا گزینه‌های اشکال‌زدایی برای مدت طولانی طراحی شده است. با این حال، توجه داشته باشید هر متغیر محیطی که پیش از پردازش فایل‌های پیکربندی لازم باشد را نمی‌توان در اینجا تنظیم کرد، زیرا هیچ تأثیری نخواهد داشت (مانند ZYPP_LOGFILE).

/usr/etc/zypp/zypp.conf
/usr/etc/zypp/zypp.conf.d/*.conf
/etc/zypp/zypp.conf
/etc/zypp/zypp.conf.d/*.conf

فایل‌های پیکربندی گوناگونی که برای پردازش در نظر گرفته می‌شوند. فایل‌های پیکربندی سیستم واقع در /etc/zypp/ (حتی اگر خالی بوده یا پیوند نمادینی به /dev/null باشند) فایل‌های پیکربندی ارائه‌دهنده با همان نام واقع در /usr/etc/zypp/ را بازنویسی خواهند کرد.

فایل‌های نهایی ابتدا به ترتیب zypp.conf و سپس zypp.conf.d/*.conf (به ترتیب الفبایی نام فایل‌ها) پردازش خواهند شد. تنظیمات بعدی، تنظیمات قبلی را بازنویسی می‌کنند.

بنابراین اساساً دو روش برای بازنویسی پیکربندی ارائه‌شده توسط توزیع واقع در /usr/etc/zypp/ وجود دارد:

•از فایل /etc/zypp/zypp.conf استفاده نکنید، بلکه از فایل‌های تکمیلی (drop-in) در /etc/zypp/zypp.conf.d/*.conf استفاده کنید. به این ترتیب، پیکربندی ارائه‌شده توسط توزیع به عنوان پیکربندی پایه استفاده می‌شود. فایل‌های تکمیلی سپس فقط باید شامل تغییرات تنظیمات خاص مد نظر شما باشند. این روش احتمالاً روش ارجح برای اغلب موارد استفاده است.
•نسخه اختصاصی خود را در /etc/zypp/zypp.conf نگهداری کنید. در این صورت، فایل ارائه‌شده توسط توزیع /usr/etc/zypp/zypp.conf نادیده گرفته می‌شود. با این حال فایل‌های تکمیلی همچنان پس از آن پردازش خواهند شد. نقطه ضعف این روش آن است که هرگونه تغییر در فایل پیکربندی ارائه‌دهنده نادیده گرفته می‌شود و باید آن‌ها را به طور دستی ادغام کنید.

همچنین ببینید: مشخصات فایل‌های پیکربندی UAPI.6 https://github.com/uapi-group/specifications/blob/main/specs/configuration_files_specification.md

نکته برای سیستم‌های قدیمی:
در حالی که توزیع‌های جدیدتر دیگر اصلاً فایل /etc/zypp/zypp.conf را ارائه نمی‌دهند، در توزیع‌های قدیمی‌تر ممکن است همچنان یک فایل کامل /etc/zypp/zypp.conf عرضه شود. اما در این حالت نیز شما از نگهداری تغییرات خود در فایل‌های تکمیلی بهره‌مند می‌شوید تا اینکه فایل عرضه‌شده /etc/zypp/zypp.conf را دستکاری کنید. اگر فایل عرضه‌شده /etc/zypp/zypp.conf دست‌نخورده باقی بماند، libzypp فایل پیکربندی را به‌روزرسانی می‌کند در حالی که تغییرات شما با خیالی آسوده در فایل‌های تکمیلی حفظ می‌شوند. با این حال، اگر فایل پیکربندی دستکاری شده باشد، libzypp آن را به‌روز نخواهد کرد و نسخه جدید را به صورت zypp.conf.rpmnew ذخیره می‌کند و باید آن‌ها را به صورت دستی ادغام کنید.

تمام نسخه‌های libzypp که از استفاده از فایل‌های تکمیلی پشتیبانی می‌کنند، قابلیت provide: libzypp(econf) و همچنین این صفحه راهنما را ارائه می‌دهند.

ZYPP_CONF

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

zypper(8)

2026-09-04 SUSE Linux