| ZYPPER(8) | ZYPPER | ZYPPER(8) |
نام (NAME)
zypper - رابط خط فرمان برای کتابخانه مدیریت سیستم ZYpp (libzypp)
خلاصه دستور (SYNOPSIS)
zypper [--global-opts] command [--command-opts] [command-arguments]
zypper subcommand [--command-opts] [command-arguments]
zypper help command
توضیحات (DESCRIPTION)
دستور zypper یک رابط خط فرمان برای کتابخانه مدیریت سیستم ZYpp (libzypp) است. از آن میتوان برای نصب، بهروزرسانی، حذف نرمافزار، مدیریت مخازن، انجام پرسوجوهای گوناگون و موارد دیگر استفاده کرد.
سیستمهای تراکنشی (Transactional systems)
در یک سیستم تراکنشی که فایلسیستم ریشه به صورت فقطخواندنی سوار (mount) شده است، دستورات zypper که سیستم را تغییر میدهند نمیتوانند مستقیماً اجرا شوند.
اگر سیستم ابزار کمکی transactional-wrapper را ارائه دهد، zypper به طور خودکار تلاش میکند آن را فراخوانی کند. این لفاف (wrapper) دستور zypper را به صورت شفاف درون یک اسنپشات جدید و با قابلیت نوشتن اجرا میکند و چرخه حیات آن اسنپشات را بر اساس وضعیت خروج دستور مدیریت مینماید.
در سیستمهای تراکنشی فاقد transactional-wrapper، کاربران باید ابزارهای تخصصی - مانند transactional-update - را به صورت دستی فراخوانی کنند تا نرمافزار را نصب، بهروزرسانی یا حذف نمایند.
مفاهیم (CONCEPTS)
بیشتر مفاهیم زیر برای تمامی برنامههای مبتنی بر کتابخانه مدیریت بسته libzypp مشترک هستند، اما برخی ویژگیهای مختص zypper نیز وجود دارند.
بستههای سیستمی (System Packages)
مجموعه بستههای نصبشده روی یک سیستم گاهی به عنوان مخزن @System یا System Packages شناخته میشود. بر خلاف مخازن موجود که بستههای قابل نصب را ارائه میدهند، @System بستههایی را ارائه میدهد که فقط میتوانند حذف شوند. بستههای نصبشدهای که توسط حداقل یکی از مخازن موجود ارائه نمیشوند (نه در نسخهای متفاوت و نه به عنوان بستهای تغییرنامیافته) اغلب به عنوان بستههای ناخواسته (unwanted)، یتیم (orphaned) یا رهاشده (dropped) در نظر گرفته میشوند.
نکته: اگر بستههایی را نصب میکنید که درون یک مخزن عرضه نمیشوند - مانند بستههایی که دستی ساخته یا دانلود شدهاند -، آنها را درون یک دایرکتوری محلی جمعآوری کرده و این دایرکتوری را به عنوان یک مخزن plaindir به سیستم خود اضافه کنید. به این ترتیب بستهها به عنوان یتیم تلقی نخواهند شد و در طول یک dist-upgrade محافظت میشوند.
ایجاد
چنین مخزن plaindir
بسیار ساده
است:
$ mkdir /LocalRepo
$ zypper addrepo --refresh /LocalRepo LocalRepo
اگر نیاز
دارید
اطمینان
حاصل کنید
که بسته
مورد نظر
برای نصب از
LocalRepo برداشته
میشود،
کافی است از
یک آرگومان
به سبک REPO:PACKAGE
استفاده
کنید:
$ cp example.rpm /LocalRepo
$ zypper install LocalRepo:example
بسته به نوع بستههایی که در مخزن محلی نگه میدارید، ممکن است بخواهید شیوه انجام بررسیهای امضای GPG را تنظیم کنید. برای جزئیات به بخش بررسیهای GPG مراجعه کنید.
مخازن (Repositories)
کتابخانه Libzypp با فرادادههای مخزن کار میکند؛ این اطلاعات درباره بستهها و روابط بین آنها است که از بستههای RPM و دادههای دیگر مانند اطلاعات وصله (patch)، تعاریف الگو (pattern) و غیره استخراج میشود. این دادهها همراه با فایلهای RPM در پوشههایی به نام مخازن (repositories) ذخیره میشوند. مخازن را میتوان روی رسانههای مختلفی مانند سرور HTTP یا FTP، دیسک DVD، یا پوشهای روی دیسک محلی قرار داد.
مجموعه خاصی از دستورات در zypper برای دستکاری مخازن در نظر گرفته شده است. همچنین بسیاری از دستورات و گزینهها یک مخزن را به عنوان آرگومان میپذیرند. برای جزئیات بیشتر به بخش دستورات (COMMANDS)، زیربخش مدیریت مخازن (Repository Management) مراجعه کنید.
بررسیهای GPG (GPG checks)
غیرفعال کردن بررسیهای GPG توصیه نمیشود. امضا کردن دادهها به گیرنده امکان میدهد تا تأیید کند پس از امضا شدن دادهها هیچ تغییری رخ نداده است. پذیرش دادههای بدون امضا، دارای امضای نادرست یا ناشناخته میتواند منجر به خراب شدن سیستم و در موارد حاد حتی به خطر افتادن امنیت سیستم شود.
کتابخانه ZYpp اصالت فرادادههای مخزن را با بررسی امضای GPG آنها تأیید میکند. اگر فرادادههای مخزن با یک کلید معتمد امضا شده باشند و با موفقیت تأیید شوند، بستههای این مخزن در صورتی که با چکسام ارائه شده در فراداده همخوانی داشته باشند، برای نصب پذیرفته میشوند. استفاده از مخازن بدون امضا نیازمند تأیید است.
اگر فرادادههای مخزن امضا نشده باشند، امضای GPG هر بسته rpm دانلود شده پیش از پذیرش آن برای نصب بررسی میشود. بستههای حاصل از مخازن بدون امضا نیازمند یک امضای معتبر GPG هستند. استفاده از بستههای بدون امضا نیازمند تأیید است.
موارد فوق رفتار پیشفرضی است که توسط تنظیمات موجود در /etc/zypp/zypp.conf تعیین میشود.
دستورات addrepo و modifyrepo گزینههای بیشتری را برای تنظیم این رفتار به ازای هر مخزن فراهم میکنند. به عنوان مثال، میتوان الزام تأیید نصب بستههای بدون امضا را برای یک مخزن خاص غیرفعال کرد. اما اگر چنین کنید، باید کاملاً مطمئن باشید که یک نفوذگر به سختی بتواند دادههای بسته را درون مخزن یا در مسیر انتقال به دستگاه شما تغییر دهد. برای جزئیات گزینههای دستور به بخش دستورات (COMMANDS) مراجعه کنید.
شناسههای منابع (URI)
برای تعیین مکان مخازن یا سایر منابع (فایلهای RPM، فایلهای repo.) میتوانید از هر نوع URI پشتیبانیشده توسط libzypp استفاده کنید. علاوه بر این، Zypper یک URI ویژه را برای شناسایی مخازن سرویس ساخت openSUSE (OBS) در دستور addrepo میپذیرد. این URIها به شکل obs://project/[platform] هستند.
برای مشاهده فهرست کامل و مثالهایی از قالبهای URI پشتیبانیشده، به بخش دستورات (COMMANDS)، زیربخش مدیریت مخازن (Repository Management) مراجعه کنید.
تازهسازی (Refresh)
تازهسازی یک مخزن به معنای دانلود فرادادههای بستهها از رسانه (در صورت نیاز)، ذخیره آن در کَش محلی (معمولاً در دایرکتوری /var/cache/zypp/raw/alias) و پیشتجزیه فرادادهها به فایلهای .solv (ساخت کَش solv)، معمولاً در /var/cache/zypp/solv/alias است.
فرادادهها یا به صورت خودکار یا به درخواست کاربر تازهسازی میشوند. یک تازهسازی خودکار دقیقاً پیش از خواندن فراداده از پایگاهداده صورت میگیرد، در صورتی که auto-refresh برای مخزن فعال باشد و فراداده به عنوان منسوخ گزارش شده باشد. اگر auto-refresh غیرفعال باشد، مخزن تنها با درخواست کاربر تازهسازی خواهد شد. شما میتوانید با فراخوانی zypper refresh درخواست تازهسازی دهید (برای جزئیات به مستندات دستور refresh مراجعه کنید).
فرادادههای مخزن پیش از انجام واقعی تازهسازی، از نظر وجود تغییرات بررسی میشوند. تغییر با دانلود یک یا دو فایل نمایه فراداده (فایلهای کوچک) و مقایسه چکسامهای فایلهای کَششده با فایلهای راه دور شناسایی میشود. اگر فایلها متفاوت باشند، مخزن منسوخ شده و تازهسازی خواهد شد.
برای به تعویق انداختن بررسی بهروز بودن (و در نتیجه تازهسازی خودکار) به مدت چند دقیقه مشخص، مقدار مشخصه repo.refresh.delay را در فایل پیکربندی ZYpp (/etc/zypp/zypp.conf) ویرایش کنید. این بدان معناست که zypper حتی تلاشی برای دانلود و بررسی فایلهای نمایه نخواهد کرد، و شما قادر خواهید بود بدون دسترسی به اینترنت یا دسترسیهای ریشه، از zypper برای عملیاتی مانند جستجو یا دریافت اطلاعات استفاده کنید.
نکته: دستور zypper -vv ref سرورهای آینهای مورد استفاده برای دانلود فراداده را نمایش میدهد.
سرویسها (Services)
سرویسها یک سطح بالاتر از مخازن قرار دارند و برای مدیریت مخازن یا انجام کارهای ویژه به کار میروند. Libzypp در حال حاضر از Repository Index Service (RIS) و Plugin Service پشتیبانی میکند.
سرویس نمایه مخزن (RIS) نوع خاصی از مخزن است که شامل فهرستی از مخازن دیگر است. این فهرست میتواند به صورت پویا توسط سرور بر اساس برخی پارامترهای URI یا نام کاربر ایجاد شود، یا میتواند ایستا باشد. هنگامی که چنین سرویسی به سیستم شما افزوده شد، zypper وظیفه افزودن، اصلاح، یا حذف این مخازن را در سیستم شما برای بازتاب فهرست فعلی به عهده میگیرد. برای جزئیات بیشتر به بخش مدیریت سرویسها (Service Management) و https://en.opensuse.org/openSUSE:Standards_Repository_Index_Service مراجعه کنید.
انواع بستهها (Package Types)
ابزار Zypper با چندین نوع شیء منبع به نام قابلحلها (resolvables) کار میکند. یک قابلحل میتواند یک package (بسته)، patch (وصله)، pattern (الگو)، یا product (محصول) باشد؛ اساساً هر نوع شیء با وابستگی به اشیاء دیگر.
package
patch
با انتخاب وصله، تعارض از طریق بهروزرسانی تمام بستههای نصبشده و آسیبدیده/آسیبپذیر به نسخهای که حاوی اصلاحیه است برطرف میشود. هنگام بهروزرسانی بستهها، zypper همیشه جدیدترین نسخه موجود را هدف قرار میدهد. وصلههای حلشده بسته به اینکه آیا به بستههای واقعاً نصبشده اشاره دارند یا خیر، به صورت applied (اعمالشده) یا not needed (غیرضروری) دستهبندی میشوند.
بنابراین نصب، بهروزرسانی یا حذف بستهها ممکن است دستهبندی وصلههای مربوط به این بستهها را تغییر دهد. از نسخه libzypp-17.23.0 به بعد، فایل /var/log/zypp/history به خاطر میسپارد که آیا یک تراکنش نهاییشده دستهبندی وصلهای را تغییر داده است یا خیر. اگر دادههای تاریخچه در دسترس باشند، جدولهای وصله ستونی را نشان میدهند که بیانگر زمانی است که وصله در وضعیت فعلی خود قرار گرفته است (since).
بسته به نوع نقص، وصلهها بر اساس دستهبندی (category) و شدت (severity) طبقهبندی میشوند. مقادیر رایج برای category عبارتند از security (امنیتی)، (recommended (توصیهشده)، bugfix (رفع اشکال))، (optional (اختیاری)، feature (قابلیت)، enhancement (بهبود))، document (مستندات) یا yast. مقادیر رایج برای severity عبارتند از critical (بحرانی)، important (مهم)، moderate (متوسط)، low (کم) یا unspecified (نامشخص). نامهای داخل پرانتز به صورت مترادف استفاده میشوند.
توجه داشته باشید که دستور patch به صورت پیشفرض وصلههای اختیاری را اعمال نمیکند (دستهبندی optional یا feature). اگر واقعاً میخواهید تمام وصلههای اختیاری به عنوان مورد نیاز در نظر گرفته شوند، دستور patch --with-optional را اجرا کنید. وصلههای خاص را میتوان با استفاده از دستور install اعمال کرد (به عنوان مثال zypper install patch:openSUSE-2014-7).
اگر صادرکننده تصمیم به پس گرفتن یک وصله منتشرشده بگیرد، وضعیت وصله به صورت retracted (پسگرفتهشده) نشان داده خواهد شد. بستههای ارائهشده توسط وصله پسگرفتهشده هنوز قابل مشاهده هستند اما دارای برچسب پسگرفتهشده (R) خواهند بود. حلکننده وابستگی از انتخاب خودکار بستههای پسگرفتهشده خودداری میکند. اگر مطمئن هستید که یک بسته پسگرفتهشده باید روی سیستم شما نصب شود، باید آن را به صراحت انتخاب کنید.
pattern
product
srcpackage
application
در سرتاسر این راهنما ما اغلب از resolvables به سادگی با عنوان بستهها (packages) و از انواع resolvable با عنوان نوع بسته یا گونه (kind) یاد خواهیم کرد. این نامهای نوع را میتوان به عنوان آرگومانهای گزینه --type در چندین دستور مانند install، info یا search به کار برد. دستورات همچنین باید اجازه دهند که اشیاء resolvable را به صورت KIND:NAME تعیین کنید (مانند patch:openSUSE-2014-7).
وابستگیهای بسته (Package Dependencies)
بستههای نرمافزاری به روشهای مختلفی به یکدیگر وابسته هستند. بستهها معمولاً به بستههای دیگر نیاز دارند (require) یا آنها را توصیه میکنند (recommend)، اما میتوانند با آنها تعارض (conflict) نیز داشته باشند. بستهها ممکن است از سختافزار یا تنظیمات زبانی خاصی پشتیبانی کنند. ابزار Zypper از یک حلکننده وابستگی (dependency solver) برای تشخیص اینکه چه بستههایی باید برای برآورده کردن درخواست کاربر نصب شوند استفاده میکند.
اگر نسخه خاصی از یک بسته را درخواست نکنید، حلکننده یک نسخه مناسب را برمیگزیند. رویکرد کلی حلکننده هنگام پردازش یک وظیفه، تمرکز بر نصب بهترین نسخه از بسته درخواستی و افزودن یا بهروزرسانی وابستگیها بر اساس نیاز است. به غیر از این حالت Focus on Job (تمرکز بر وظیفه) که حالت پیشفرض است، دو حالت تمرکز دیگر نیز در دسترس هستند:
در حالت Focus on Installed (تمرکز بر موارد نصبشده)، حلکننده بر اعمال کمترین تغییرات ممکن روی بستههای نصبشده تمرکز میکند. انتخاب نسخهای قدیمیتر از یک بسته درخواستی در صورتی که وابستگیهای آن به تغییرات کمتری در سیستم نیاز داشته باشند معتبر است. حلکننده تلاش خواهد کرد تا از بهروزرسانی بستههای از قبل نصبشده اجتناب کند.
در حالت Focus on Update (تمرکز بر بهروزرسانی)، حلکننده بر بهروزرسانی بسته درخواستی و تمام وابستگیهای آن تا حد ممکن تمرکز میکند. توجه داشته باشید که نصب یک تکبسته در این حالت به راحتی میتواند منجر به یک بهروزرسانی سراسری کوچک در سیستم شود.
برای یک دستور واحد، حالت تمرکز را میتوان با استفاده از سوییچ --solver-focus MODE تنظیم کرد. حالتهای معتبر عبارتند از Job، Installed یا Update. اگر میخواهید حالت پیشفرض را برای سیستم خود تغییر دهید، مقدار [/etc/zypp/zypp.conf:solver.focus] را روی مقدار مورد نظر تنظیم کنید.
بستههای نصبشده خودکار (Automatically installed packages)
بستههایی که توسط حلکننده وابستگی به منظور رفع درخواست کاربر اضافه میشوند، به عنوان بستههای بهطور خودکار نصبشده به خاطر سپرده میشوند. این بستهها ممکن است بعداً در صورتی که هیچ بسته نصبشده توسط کاربر به آنها وابسته نباشد، حذف شوند (مثلاً با دستور zypper remove --clean-deps).
در ستون Status، دستور search بین بستههای نصبشده توسط کاربر (i+) و بستههای بهطور خودکار نصبشده (i) تمایز قائل میشود.
تعارضهای فایل بسته (Package File Conflicts)
تعارض فایل زمانی رخ میدهد که دو بسته تلاش کنند فایلهایی با نام یکسان اما محتوای متفاوت نصب نمایند. این حالت ممکن است زمانی رخ دهد که در حال نصب نسخه جدیدتری از یک بسته بدون پاک کردن نسخه قدیمیتر باشید، یا زمانی که دو بسته نامرتبط هر کدام فایلی با نام یکسان نصب کنند.
از آنجا که بررسی تعارض فایل نیازمند دسترسی به فهرست کامل فایلهای هر بسته در حال نصب است، zypper تنها در صورتی قادر به بررسی تعارض فایل خواهد بود که همه بستهها از قبل دانلود شده باشند (به --download-in-advance مراجعه کنید). اگر از --dry-run استفاده میکنید، هیچ بستهای دانلود نمیشود، بنابراین بررسی تعارض فایل از بستههایی که در کَش بستهها موجود نیستند صرفنظر خواهد کرد. برای انجام یک بررسی معنادار تعارض فایل، از --dry-run به همراه --download-only استفاده کنید.
از آنجا که علت تعارض فایل معمولاً طراحی ضعیف بسته یا عدم هماهنگی بین سازندگان بستهها است، حل آنها ساده نیست. با استفاده از گزینه --replacefiles میتوانید zypper را وادار به جایگزینی فایلهای دارای تعارض کنید. با این وجود، این کار ممکن است به بستهای که فایل آن جایگزین میشود آسیب برساند.
دستورات (COMMANDS)
ابزار zypper مجموعهای از دستورات را فراهم میکند. هر دستور گزینههای فهرستشده در بخش گزینههای سراسری (GLOBAL OPTIONS) را میپذیرد. این گزینهها باید پیش از نام دستور مشخص شوند. علاوه بر این، بسیاری از دستورات دارای گزینههای ویژهای هستند که در این بخش فهرست شدهاند. این گزینههای مختص دستور باید پس از نام دستور و پیش از هر یک از آرگومانهای دستور مشخص شوند.
ابزار Zypper همچنین پشتیبانی محدودی از نوشتن افزونهها/زیردستورها به هر زبانی ارائه میدهد. برای جزئیات به بخش زیردستورها (SUBCOMMANDS) مراجعه کنید.
دستورات عمومی (General Commands)
help [command]
اگر با یک آرگومان نام command اجرا شود، در صورتی که چنین دستوری وجود داشته باشد، zypper راهنمای دستور مشخصشده را نمایش میدهد. هر دو نگارش بلند و کوتاه نامهای دستورات قابل استفاده هستند.
برای راحتی شما، zypper help را میتوان به هر یک از روشهای زیر نیز فراخوانی کرد:
shell (sh)
پشتیبانی از پوسته کامل نیست، بنابراین انتظار وجود اشکالاتی در آن داشته باشید. با این حال، به لطف سریع شدن چشمگیر libzypp با حلکننده SAT و ابزارهای آن (openSUSE 11.0)، نیاز مبرمی به استفاده از پوسته وجود ندارد، اما با این حال میتوانید با آن آزمایش کنید.
دستورات مدیریت بسته (Package Management Commands)
info (if) [options] name[-version[-release]]...
اگر هیچ قید نسخهای مشخص نشده باشد، اطلاعات مربوط به بهترین بسته موجود نمایش داده میشود. توجه داشته باشید که هر دو شماره نسخه و انتشار باید همیشه دقیقاً مطابقت داشته باشند.
اگر یک پرسوجو هیچ نتیجهای در بر نداشته باشد، zypper مقدار ZYPPER_EXIT_INF_CAP_NOT_FOUND را بازمیگرداند مگر اینکه گزینه سراسری --ignore-unknown تنظیم شده باشد.
-s, --match-substrings
-r, --repo alias|name|#|URI
-t, --type type
--provides
--requires
--conflicts
--obsoletes
--recommends
--suggests
--supplements
--enhances
مثالها:
$ zypper info workrave
$ zypper info -t patch libzypp
$ zypper info -t pattern lamp_server
install (in) [options] name|capability|rpm_file_uri...
بستهها را میتوان بر اساس name (نام) آنها یا بر اساس یک capability (قابلیت) که ارائه میدهند انتخاب کرد.
یک قابلیت به صورت "NAME[.ARCH][ OP EDITION]" تشکیل میشود، که در آن ARCH کد معماری است، OP یکی از <، <=، =، >= یا > است و EDITION به صورت "VERSION[-RELEASE]" میباشد. برای مثال: zypper=0.8.8-2.
جزء NAME در یک قابلیت نه تنها نام یک بسته، بلکه هر نماد ارائهشده توسط بستهها است: /bin/vi، libcurl.so.3، perl(Time::ParseDate). فقط به یاد داشته باشید که برای محافظت از نویسههای خاص در برابر پوسته از نقلقول استفاده کنید، برای مثال: zypper\>0.8.10 یا 'zypper>0.8.10'.
اگر EDITION مشخص نشده باشد، جدیدترین نسخه قابل نصب، نصب خواهد شد. این بدان معناست که اگر بسته از قبل نصب شده باشد و نسخههای جدیدتری در دسترس باشند، به جدیدترین نسخه قابل نصب ارتقا مییابد.
اگر ARCH مشخص نشده باشد، یا آخرین نقطه در رشته نام قابلیت با یک معماری شناختهشده دنبال نشود، حلکننده با کل رشته به عنوان یک نام قابلیت رفتار خواهد کرد. اگر ARCH شناختهشده باشد، حلکننده بستهای مطابق با آن معماری را انتخاب میکند و در صورت نیافتن چنین بستهای خطا میدهد.
اگر میخواهید اطمینان حاصل کنید که بستهای از یک REPOSITORY خاص انتخاب میشود، از REPOSITORY:PACKAGENAME به عنوان آرگومان استفاده کنید.
ابزار Zypper همچنین قادر به نصب فایلهای ساده RPM است در حالی که تلاش میکند وابستگیهای آنها را با استفاده از بستههای مخازن تعریفشده برطرف کند. میتوانید یک فایل ساده RPM را با مشخص کردن مکان آن در آرگومانهای دستور install به صورت یک مسیر محلی یا یک URI نصب کنید. به عنوان مثال:
$ zypper install ~/rpms/foo.rpm http://some.site/bar.rpm
ابزار Zypper بستههایی را که نتواند پیدا کند گزارش خواهد داد. علاوه بر این، در حالت تعاملی، zypper به نصب بقیه بستههای درخواستی ادامه میدهد، و در حالت غیرتعاملی فوراً متوقف میشود. در هر دو حالت، zypper پس از اتمام عملیات مقدار ZYPPER_EXIT_INF_CAP_NOT_FOUND را بازمیگرداند.
ابزار Zypper فایلها را در یک مخزن موقت plaindir جمعآوری کرده و بستههای مربوطه را برای نصب علامتگذاری میکند. اگر از --download-only استفاده شود، بستههای دانلودشده تا زمانی که واقعاً آنها را نصب کنید یا دستور zypper clean را برای پاکسازی کَشهای بسته اجرا نمایید، در /var/cache/zypper/RPMS در دسترس خواهند بود. آنها بخشی از کَش سراسری بسته در /var/cache/zypp/packages نخواهند شد (همچنین به گزینه سراسری --pkg-cache-dir مراجعه کنید).
در دستور install، میتوانید بستههایی را که میخواهید حذف شوند نیز با افزودن نویسه - یا ! به ابتدای نام آنها مشخص کنید. برای مثال:
$ zypper install \!Firefox
بر خلاف zypper remove Firefox که فایرفاکس و بستههای وابسته به آن را حذف میکند، دستور install تلاش میکند با جستجوی جایگزینهای فایرفاکس، بستههای وابسته را نصبشده نگه دارد.
توجه داشته باشید که اگر تصمیم گرفتید از - با اولین بستهای که مشخص میکنید استفاده کنید، باید -- را قبل از آن بنویسید تا از تفسیر آن به عنوان یک گزینه دستور جلوگیری شود:
$ zypper install -- -boring-game great-game great-game-manual
-r, --repo alias|name|#|URI
استفاده از --repo توصیه نمیشود زیرا در حال حاضر مخازن ذکرنشده را از حلکننده پنهان میکند و منجر به تصمیمگیریهای غیربهینه میشود. در آینده --repo به یک نام مستعار برای --from تبدیل خواهد شد.
اگر میخواهید بستهای را از یک مخزن خاص نصب کنید، از REPOSITORY:PACKAGENAME به عنوان آرگومان استفاده کنید.
-t, --type type
اگر patch مشخص شود، zypper بستهها را برای برآورده کردن وصله مشخصشده نصب و/یا حذف خواهد کرد. این روشی برای اطمینان از نصب یک رفع اشکال خاص است. برای یافتن وصلههای قابل اعمال از zypper list-patches استفاده کنید.
اگر product یا pattern مشخص شود، zypper اطمینان حاصل میکند که تمام بستههای مورد نیاز (و در صورت تمایل توصیهشده) نصب شوند.
-n, --name
-f, --force
--oldpackage
--from alias|name|#|URI
-C, --capability
-l, --auto-agree-with-licenses
--auto-agree-with-product-licenses
--replacefiles
-D, --dry-run
--details
-y, --no-confirm
--allow-unsigned-rpm
گزینههای مربوط به حلکننده (Solver):
--debug-solver
--force-resolution
به منظور انجام وظیفه درخواستی، حلکننده مجاز است هر خطمشی فعالی را نقض کند. این شامل مجوز حذف بستهها و همچنین نادیده گرفتن خطمشیهای صراحتاً تنظیمشده (توسط --no-allow-policy یا در فایلهای کانفیگ) میباشد. استفاده از این گزینه در محیطهای بدون نظارت توصیه نمیشود.
مجوز حذف بستههای وابسته، هنگام حذف بستهها (zypper remove) رفتار پیشفرض است.
-R, --no-force-resolution
--solver-focus MODE
--recommends
--no-recommends
گزینههای حالت دانلود و نصب:
-d, --download-only
اگر همراه با --dry-run استفاده شود، میتوان بررسی معناداری از تعارضهای فایل انجام داد (به بخش تعارضهای فایل بسته (Package File Conflicts) مراجعه کنید).
--download-in-advance
--download-in-heaps
نکته
تا زمانی که حلکننده قادر به ساخت دستهها نباشد، این گزینه رفتاری مشابه با --download-in-advance خواهد داشت.
--download-as-needed
--download mode
گزینههای پیشرفته (Expert Options):
--allow-downgrade, --no-allow-downgrade
--allow-name-change, --no-allow-name-change
--allow-arch-change, --no-allow-arch-change
--allow-vendor-change, --no-allow-vendor-change
مثالها:
$ zypper install -t pattern lamp_server
$ zypper install --no-recommends gv
$ zypper install virtualbox-ose-2.0.6
$ zypper install virtualbox-ose=2.0.6
$ zypper install virtualbox-ose = 2.0.6
source-install (si) name...
این دستور تلاش خواهد کرد تا جدیدترین نسخههای موجود بستههای منبع را پیدا کرده و از rpm -i برای نصب آنها استفاده کند، به صورت اختیاری همراه با تمامی بستههایی که برای ساخت بسته منبع مورد نیاز است. مکان پیشفرضی که rpm بستههای منبع را در آن نصب میکند /usr/src/packages/{SPECS,SOURCES} است، اما این مقادیر را میتوان در پیکربندی محلی rpm تغییر داد. در صورت تردید، اجرای rpm --eval "%{_specdir} and %{_sourcedir}" را امتحان کنید.
توجه داشته باشید که بستههای منبع باید در مخازنی که استفاده میکنید موجود باشند. با استفاده از دستور زیر میتوانید بررسی کنید که آیا یک مخزن حاوی بسته منبع است یا خیر:
-d, --build-deps-only
-D, --no-build-deps
-r, --repo alias|name|#|URI
--download-only
مثالها:
$ zypper si -d dbus-1
verify (ve) [options]
در صورتی که هرگونه مشکل وابستگی پیدا شود، zypper بستههایی را برای نصب یا حذف جهت رفع آنها پیشنهاد میدهد.
-D, --dry-run
--details
-r, --repo alias|name|#|URI
-y, --no-confirm
گزینههای مربوط به حلکننده (Solver):
--debug-solver
--force-resolution
به منظور انجام وظیفه درخواستی، حلکننده مجاز است هر خطمشی فعال در غیر این صورت را نقض کند. این شامل مجوز حذف بستهها و همچنین عدم رعایت حتی خطمشیهای صراحتاً تعیینشده (توسط --no-allow-policy یا در فایلهای پیکربندی) است. استفاده از این گزینه در محیطهای بدون نظارت توصیه نمیشود.
مجوز حذف بستههای وابسته هنگام حذف بستهها (zypper remove) حالت پیشفرض است.
-R, --no-force-resolution
--solver-focus MODE
--recommends
--no-recommends
گزینههای پیشرفته:
--allow-downgrade, --no-allow-downgrade
--allow-name-change, --no-allow-name-change
--allow-arch-change, --no-allow-arch-change
--allow-vendor-change, --no-allow-vendor-change
این دستور همچنین گزینههای حالت بارگیری و نصب شرحدادهشده در دستور install را میپذیرد.
install-new-recommends (inr) [options]
در صورت فراخوانی به صورت zypper inr --no-recommends، دستور محدود میشود تا فقط به دنبال بستههایی باشد که از سختافزارها، زبانها یا سیستمهای فایل موجود پشتیبانی میکنند. این امر پس از افزودن مثلاً سختافزار جدید یا مخازن درایور مفید است. همچنین اگر [zypp.conf:solver.onlyRequires] را تنظیم کرده باشید، این رفتار پیشفرض خواهد بود.
-r, --repo alias|name|#|URI
-D, --dry-run
--details
گزینههای مربوط به حلکننده (Solver):
--debug-solver
--force-resolution
به منظور انجام وظیفه درخواستی، حلکننده مجاز است هر خطمشی فعال در غیر این صورت را نقض کند. این شامل مجوز حذف بستهها و همچنین عدم رعایت حتی خطمشیهای صراحتاً تعیینشده (توسط --no-allow-policy یا در فایلهای پیکربندی) است. استفاده از این گزینه در محیطهای بدون نظارت توصیه نمیشود.
مجوز حذف بستههای وابسته هنگام حذف بستهها (zypper remove) حالت پیشفرض است.
-R, --no-force-resolution
--solver-focus MODE
--recommends
--no-recommends
گزینههای پیشرفته:
--allow-downgrade, --no-allow-downgrade
--allow-name-change, --no-allow-name-change
--allow-arch-change, --no-allow-arch-change
--allow-vendor-change, --no-allow-vendor-change
این دستور همچنین گزینههای حالت بارگیری و نصب شرحدادهشده در دستور install را میپذیرد.
remove (rm) [options] name...
remove (rm) [options] --capability capability...
دستور remove بستههای انتخابشده و بستههای وابسته به آنها را لغو نصب میکند. این دستور برای نگه داشتن بستههای وابسته، تلاشی برای نصب گزینههای جایگزین نخواهد کرد. اگر این رفتار را میخواهید، از zypper install !name استفاده کنید.
بستهها را میتوان بر اساس نام آنها یا قابلیتی که ارائه میدهند انتخاب کرد. برای جزئیات در مورد انتخاب بسته، به توضیحات دستور install مراجعه کنید.
-r, --repo alias|name|#|URI
-t, --type type
از آنجا که وصلهها (patches) به مفهوم کپی کردن فایلها یا ثبت یک مدخل در پایگاهداده نصب نمیشوند، نمیتوان آنها را لغو نصب کرد؛ حتی با اینکه zypper آنها را به صورت نصبشده نمایش میدهد. وضعیت نصبشده صرفاً بر اساس وضعیت نصب وابستگیهای مورد نیاز آن تعیین میشود. اگر این وابستگیها برآورده شده باشند، وصله به عنوان نصبشده در نظر گرفته میشود.
-n, --name
-C, --capability
-D, --dry-run
--details
-y, --no-confirm
گزینههای مربوط به حلکننده (Solver):
--debug-solver
--force-resolution
به منظور انجام وظیفه درخواستی، حلکننده مجاز است هر خطمشی فعال در غیر این صورت را نقض کند. این شامل مجوز حذف بستهها و همچنین عدم رعایت حتی خطمشیهای صراحتاً تعیینشده (توسط --no-allow-policy یا در فایلهای پیکربندی) است. استفاده از این گزینه در محیطهای بدون نظارت توصیه نمیشود.
مجوز حذف بستههای وابسته هنگام حذف بستهها (zypper remove) حالت پیشفرض است.
-R, --no-force-resolution
--solver-focus MODE
-u, --clean-deps
-U, --no-clean-deps
removeptf (rmptf) [options] <PTF|CAPABILITY> ...
یک دستور حذف که جایگزینی بستههای وابسته را به حذف آنها نیز ترجیح میدهد. در واقع این یک دستور کامل install همراه با اصلاحکننده حذف (-) است که روی آرگومانهای ساده آن اعمال شده است. بنابراین removeptf foo معادل install — -foo است. به همین دلیل است که این دستور همان گزینههای دستور install را میپذیرد. این روش توصیهشده برای حذف یک PTF (اصلاحیه موقت برنامه یا Program Temporary Fix) است.
یک PTF معمولاً به محض اینکه اصلاحیه ارائهشده توسط آن در آخرین بهروزرسانی رسمی بستههای وابسته اعمال شود، حذف میگردد. اما شما نمیخواهید بستههای وابسته همراه با PTF حذف شوند؛ کاری که دستور remove انجام میدهد. با این حال دستور removeptf تلاش خواهد کرد تا بستههای وابسته را با نسخههای بهروزرسانی رسمی آنها جایگزین کند.
از تمامی گزینههایی که دستور install پشتیبانی میکند، پشتیبانی میکند
purge-kernels [options]
پاکسازی خودکار هستههای نصبشده مطابق با قوانین تعریفشده در [zypp.conf:multiversion.kernels] که میتوانند به صورت <version>، latest[-N]، running، oldest[+N] مشخص شوند.
--details
-D, --dry-run
دستورات مدیریت بهروزرسانی (Update Management Commands)
list-updates (lu) [options]
این دستور فقط بهروزرسانیهای قابلنصب را فهرست میکند؛ یعنی بهروزرسانیهایی که فاقد مشکل وابستگی بوده یا ارائهدهنده (vendor) بسته را تغییر نمیدهند. این فهرست شامل مواردی است که دستور update برای نصب پیشنهاد خواهد کرد. برای فهرست کردن تمام بستههایی که نسخه جدیدتری از آنها در دسترس است، از گزینه --all استفاده کنید.
-t, --type type
اگر patch مشخص شود، zypper بهگونهای عمل میکند که گویی دستور list-patches اجرا شده است.
-r, --repo alias|name|#|URI
-a, --all
--best-effort
--filter-version-change LEVEL
none
rebuild
package
تغییرات Epoch هرگز فیلتر نمیشوند. این گزینه برای وصلهها (patches) اعمال نمیشود (به جای آن از فیلترهای list-patches استفاده کنید).
گزینههای پیشرفته (Expert Options):
--allow-downgrade, --no-allow-downgrade
--allow-name-change, --no-allow-name-change
--allow-arch-change, --no-allow-arch-change
--allow-vendor-change, --no-allow-vendor-change
update (up) [options] [packagename]...
این دستور بستههایی را که نیازمند تغییر ارائهدهنده بسته باشند بهروزرسانی نخواهد کرد، مگر اینکه ارائهدهنده در /etc/zypp/vendors.d مشخص شده باشد، یا نیازمند حل دستی مشکلات وابستگیها باشند. چنین بهروزرسانیهای غیرقابلنصبی در بخش جداگانهای از خلاصه وضعیت با عنوان "The following package updates will NOT be installed:" فهرست خواهند شد.
برای بهروزرسانی بستههای منفرد، یک یا چند نام بسته را مشخص کنید. میتوانید از نویسههای عامهنمای (wildcard) * و ? در نام بستهها برای مشخص کردن چندین بسته منطبق با الگو استفاده کنید.
-t, --type type
اگر patch مشخص شود، zypper بهگونهای عمل میکند که گویی دستور patches اجرا شده است.
-r, --repo alias|name|#|URI
--skip-interactive
--with-interactive
-l, --auto-agree-with-licenses
--auto-agree-with-product-licenses
--replacefiles
-D, --dry-run
--details
--best-effort
-y, --no-confirm
گزینههای مربوط به حلکننده وابستگیها (Solver related options):
--debug-solver
--force-resolution
به منظور انجام کار درخواستی، حلکننده مجاز است هر خطمشی که در حالت عادی فعال است را نقض کند. این شامل مجوز حذف بستهها و همچنین عدم رعایت خطمشیهایی است که صریحاً تنظیم شدهاند (توسط --no-allow-policy یا در فایلهای کانفیگ). استفاده از این گزینه در محیطهای بدون نظارت توصیه نمیشود.
مجوز حذف بستههای وابسته، هنگام حذف بستهها (zypper remove) رفتار پیشفرض است.
-R, --no-force-resolution
--solver-focus MODE
--recommends
--no-recommends
گزینههای پیشرفته (Expert Options):
--allow-downgrade, --no-allow-downgrade
--allow-name-change, --no-allow-name-change
--allow-arch-change, --no-allow-arch-change
--allow-vendor-change, --no-allow-vendor-change
این دستور همچنین گزینههای حالت بارگیری و نصب (Download-and-install mode options) شرح داده شده در توضیحات دستور install را میپذیرد.
list-patches (lp) [options]
این دستور مشابه zypper list-updates -t patch است.
توجه داشته باشید که آرگومانهای اختیاری برخی از گزینههای زیر باید با استفاده از = به جای فاصله مشخص شوند.
-b, --bugzilla[=#[,...]]
--cve[=#[,...]]
--date YYYY-MM-DD[,...]
-g, --category category[,...]
--severity severity[,...]
--issue[=string[,...]]
-a, *--all
--with-optional, --without-optional
-r, --repo alias|name|#|URI
patch-check (pchk)
همچنین برای جزئیات در مورد وضعیتهای خروج 0، 100 و 101 بازگرداندهشده توسط این دستور، بخش EXIT CODES را ببینید.
--updatestack-only
--with-optional, --without-optional
-r, --repo alias|name|#|URI
patch [options]
هنگام بهروزرسانی بستههای تحتتاثیر قرار گرفته/آسیبپذیر شرح داده شده توسط یک وصله، zypper همیشه جدیدترین نسخه موجود را هدف قرار میدهد. برای جزئیات بیشتر درباره نحوه عملکرد وصلهها، بخش Package Types را ببینید.
اگر وصلههایی وجود داشته باشند که بر خود مدیریت بستهها اثر میگذارند، ابتدا آنها نصب خواهند شد و از شما خواسته میشود دستور patch را مجدداً اجرا کنید.
این دستور مشابه zypper update -t patch است.
--updatestack-only
--skip-not-applicable-patches
در محیطهای اسکریپتی و بدون نظارت، ممکن است تمایل داشته باشید حداقل تا جای ممکن وصلهها اعمال شوند تا سیستم کاملاً بدون بهروزرسانی نماند. اکیداً توصیه میشود پس از آن دستور zypper patch-check را اجرا کنید تا ببینید آیا وصلههای مورد نیازی وجود دارند که همچنان منتظر حل تعاملی باشند.
--with-update
اگر دستور وصله ابتدا نیاز به بهروزرسانی پشته بهروزرسانی (update stack) داشته باشد، این گزینه نادیده گرفته میشود؛ بنابراین نمیتوان آن را با گزینه --updatestack-only ترکیب کرد.
--with-optional, --without-optional
-b, --bugzilla #[,...]
--cve #[,...]
--date YYYY-MM-DD[,...]
-g, --category category[,...]
--severity severity[,...]
-r, --repo alias|name|#|URI
--skip-interactive
--with-interactive
-l, --auto-agree-with-licenses
--auto-agree-with-product-licenses
--replacefiles
-D, --dry-run
--details
-y, --no-confirm
گزینههای مربوط به حلکننده وابستگیها (Solver related options):
--debug-solver
--force-resolution
به منظور انجام کار درخواستی، حلکننده مجاز است هر خطمشی که در حالت عادی فعال است را نقض کند. این شامل مجوز حذف بستهها و همچنین عدم رعایت خطمشیهایی است که صریحاً تنظیم شدهاند (توسط --no-allow-policy یا در فایلهای کانفیگ). استفاده از این گزینه در محیطهای بدون نظارت توصیه نمیشود.
مجوز حذف بستههای وابسته، هنگام حذف بستهها (zypper remove) رفتار پیشفرض است.
-R, --no-force-resolution
--solver-focus MODE
--recommends
--no-recommends
گزینههای پیشرفته (Expert Options):
--allow-downgrade, --no-allow-downgrade
--allow-name-change, --no-allow-name-change
--allow-arch-change, --no-allow-arch-change
--allow-vendor-change, --no-allow-vendor-change
این دستور همچنین گزینههای حالت بارگیری و نصب (Download-and-install mode options) شرح داده شده در توضیحات دستور install را میپذیرد.
dist-upgrade (dup) [options]
اگر هیچ مخزنی از طریق گزینه --from مشخص نشده باشد، zypper یک ارتقای سراسری با تمام مخازن تعریفشده انجام خواهد داد. این حالت سراسری dup بستههای بدون تغییر نصبشده را نیز مد نظر قرار داده و وابستگیهای آنها را مجدداً ارزیابی میکند. اگر سیستم حاوی مخازن متناقض باشد (مانند مخازن دو انتشار مختلف توزیع)، این امر میتواند مشکلساز شود. این حالت اغلب زمانی رخ میدهد که کاربر پس از افزودن مخزن یک انتشار جدید، فراموش کند مخزن انتشار قدیمیتر را حذف کند؛ مثلاً openSUSE 13.1 و openSUSE 13.2.
برای تمام مخازنی که نسخه توزیع را درون نشانی URL خود دارند (مانند https://download.opensuse.org/distribution/13.1/repo/oss)، استفاده از متغیر $releasever به جای آن میتواند مفید باشد (https://download.opensuse.org/distribution/$releasever/repo/oss). این متغیر به طور پیشفرض با نسخه فعلی توزیع (13.1) جایگزین میشود.
این مقدار را میتوان به صورت موقت در دستور جاری zypper با استفاده از گزینه عمومی --releasever بازنویسی کرد. فراخوانی دستور بهصورت zypper --releasever 13.2... باعث میشود این مخازن بدون نیاز به افزودن یا حذف هیچ موردی، از مکان جدید (https://download.opensuse.org/distribution/13.2/repo/oss) استفاده کنند. اما تا زمانی که ارتقای توزیع عملاً انجام شود، باید از --releasever 13.2 همراه با هر دستور zypper استفاده کنید. پس از پایان عملیات dup، مقدار $releasever به طور پیشفرض نسخه جدید توزیع 13.2 خواهد بود و دیگر به --releasever نیازی نیست.
تنظیم دائمی $releasever روی مقدار توزیع هدف میتواند زحمت کمتری داشته باشد تا اصلاً نیازی به --releasever نباشد. برای اطلاعات بیشتر درباره جایگزینی متغیرها و تعریف متغیرهای سفارشی، بخش Repository Management را ببینید.
یادداشت: اجرای ارتقای توزیع به طور خودکار یک مورد آزمایشی حلکننده در /var/log/updateTestcase-YYYY-MM-DD-hh-mm-ss (تاریخ و زمان اجرای دستور) ایجاد خواهد کرد.
یادداشت: ارتقای توزیع در openSUSE در حال حاضر فقط بین انتشارهای متوالی پشتیبانی میشود. برای ارتقا در میان چند انتشار، هر انتشار متوالی را یکییکی ارتقا دهید. برای جزئیات بیشتر به نشانی http://en.opensuse.org/SDB:System_upgrade و یادداشتهای انتشار openSUSE در نشانی http://doc.opensuse.org/release-notes. مراجعه فرمایید.
یادداشت: به دلیل نحوه برخورد با بستههای یتیم، dist-upgrade بیش از هر دستور دیگری به پیکربندی صحیح مخازن وابسته است. در صورتی که بازخوانی مخازن فعال ناموفق باشد، این دستور نباید ادامه یابد، زیرا این امر میتواند آسیب شدیدی به سیستم وارد کند. اگر مخزن دارای خطا در واقع مورد نیاز نیست، باید غیرفعال شود.
--from alias|name|#|URI
--remove-orphaned
'یادداشت:' بستههایی که درون یک مخزن عرضه نشدهاند - بستههای دستساز یا بارگیریشده - را میتوان در یک مخزن plaindir جمعآوری کرد تا از برخورد با آنها به عنوان بسته یتیم جلوگیری شود. برای جزئیات، بخش *System Packages* را ببینید.
-r, --repo alias|name|#|URI
استفاده از --repo توصیه نمیشود زیرا در حال حاضر مخازن ذکرنشده را از دید حلکننده پنهان میکند و منجر به تصمیمگیریهای غیرکارشناسانه میشود. دلیل این امر آن است که بستههایی که در ابتدا از مخازن پنهانشده نصب شده بودند، اکنون به عنوان یتیم یا حذفشده تلقی میشوند و اگر در تداخل وابستگی دخیل باشند ممکن است بدون اعلان حذف شوند. در آینده --repo به یک نام مستعار برای --from تبدیل خواهد شد.
-l, --auto-agree-with-licenses
--auto-agree-with-product-licenses
--replacefiles
-D, --dry-run
-y, --no-confirm
--details
گزینههای مربوط به حلکننده وابستگیها (Solver related options):
--debug-solver
--force-resolution
به منظور انجام کار درخواستی، حلکننده مجاز است هر خطمشی که در حالت عادی فعال است را نقض کند. این شامل مجوز حذف بستهها و همچنین عدم رعایت خطمشیهایی است که صریحاً تنظیم شدهاند (توسط --no-allow-policy یا در فایلهای کانفیگ). استفاده از این گزینه در محیطهای بدون نظارت توصیه نمیشود.
مجوز حذف بستههای وابسته، هنگام حذف بستهها (zypper remove) رفتار پیشفرض است.
-R, --no-force-resolution
--solver-focus MODE
--recommends
--no-recommends
گزینههای پیشرفته (Expert Options):
--allow-downgrade, --no-allow-downgrade
--allow-name-change, --no-allow-name-change
--allow-arch-change, --no-allow-arch-change
--allow-vendor-change, --no-allow-vendor-change
این دستور همچنین گزینههای حالت بارگیری و نصب (Download-and-install mode options) شرح داده شده در توضیحات دستور install را میپذیرد.
مثالها (Examples):
$ zypper dup --from factory --from packman
دستورات پرسوجو (Query Commands)
search (se) [options] [querystring|capability]...
اگر رشته جستجو با یک / آغاز شود، نام یک فایل فرض میشود و جستجو به طور خودکار درون فهرست فایلهای بستهها را بررسی میکند. در غیر این صورت از -f استفاده کنید تا در فهرست فایلهای بستهها نیز جستجو شود.
نتایج جستجو در یک جدول با ستونهای وضعیت (Status)، نام (Name)، خلاصه (Summary) و نوع (Type) بسته چاپ میشوند. در صورتی که نتیجه پرسوجو خالی باشد، zypper مقدار ZYPPER_EXIT_INF_CAP_NOT_FOUND را برمیگرداند، مگر اینکه گزینه سراسری --ignore-unknown تنظیم شده باشد.
در نمای پرجزئیات (se -s)، تمام نمونههای موجود از بستههای منطبق نشان داده میشوند؛ هر نسخه در هر مخزن در یک خط جداگانه، با ستونهای وضعیت (Status)، نام (Name)، نوع (Type)، نسخه (Version)، معماری (Architecture) و مخزن (Repository). برای بستههای نصبشده، ستون Repository یا مخزنی را نشان میدهد که دقیقاً نسخه نصبشده بسته را ارائه میدهد، یا اگر نسخه دقیق توسط هیچ مخزن شناختهشدهای ارائه نشود، (System Packages) (یا @System) را نمایش میدهد. آن دسته از بستههای نصبشده که توسط هیچ مخزنی ارائه نمیشوند، اغلب به عنوان ناخواسته (unwanted)، یتیم (orphaned) یا کنارگذاشتهشده (dropped) مشخص میشوند.
ستون وضعیت (Status) میتواند شامل مقادیر زیر باشد:
i+
i
v
empty
!
.l
.P
.R
نمای پرجزئیات (se -v؛ که متضمن -s است) همچنین خود موارد منطبق را درون متادیتای بستهها نشان میدهد.
این دستور گزینههای زیر را میپذیرد:
--match-substrings
--match-words
-x, --match-exact
--provides
--requires
--recommends
--suggests
--conflicts
--obsoletes
--supplements
--enhances
--provides-pkg
--requires-pkg
--recommends-pkg
--supplements-pkg
--conflicts-pkg
--obsoletes-pkg
--suggests-pkg
--enhances-pkg
-n, --name
-f, --file-list
-d, --search-descriptions
-C, --case-sensitive
-i, --installed-only
-u, --not-installed-only
نام قدیمی گزینه --uninstalled-only همچنان قابل قبول است، اما باید منسوخ تلقی شود.
-t, --type type
همچنین دستورات پرسوجوی ویژه هر نوع مانند packages، patterns و غیره را ببینید.
-r, --repo alias|name|#|URI
--sort-by-name
--sort-by-repo
-s, --details
-v, --verbose
مثالها:
$ zypper se 'yast*'
$ zypper se -s --match-exact kernel-default
$ zypper se -dC --match-words RSI
packages (pa) [options] [repository]...
-r, --repo alias|name|#|URI
-i, --installed-only
-u, --not-installed-only
نام قدیمی گزینه --uninstalled-only همچنان قابل قبول است، اما باید منسوخ تلقی شود.
*--autoinstalled
--userinstalled
--system
--orphaned
--suggested
--recommended
--unneeded
patches (pch) [options] [repository]...
-r, --repo alias|name_|#|URI
patterns (pt) [options] [repository]...
-r, --repo alias|name|#|URI
-i, --installed-only
-u, --not-installed-only
نام قدیمی گزینه --uninstalled-only همچنان قابل قبول است، اما باید منسوخ تلقی شود.
products (pd) [options] [repository]...
-r, --repo alias|name|#|URI
-i, --installed-only
-u, --not-installed-only
نام قدیمی گزینه --uninstalled-only همچنان قابل قبول است، اما باید منسوخ تلقی شود.
--xmlfwd tag
با استفاده از این گزینه، برای هر محصول نصبشده یک گره <xmlfwd> در داخل گره خروجی <product> آن محصول ایجاد میشود.
آرگومان Tag نام (یا مسیر جداشده با /) یک تگ xml درون فایل prod.- محصول نصبشده را مشخص میکند. اگر این تگ درون فایل prod.- محصول وجود داشته باشد، تگ و محتوای آن دقیقاً به گره خروجی <xmlfwd> محصول هدایت میشود.
این گزینه میتواند چندین بار مشخص شود.
مثالها:
$ zypper -x pd --xmlfwd name --xmlfwd register/target
what-provides (wp) capability
خط فرمان بهطور خودکار به دستور متناظر search تبدیل میشود:
$ zypper what-provides 'zypper>1.6'
برای یک جستجوی حساس به بزرگی و کوچکی حروف، اجرا کنید:
مدیریت مخازن (Repository Management)
زیپر قادر به کار با مخازن نرمافزاری YaST، RPM-MD (yum) و پوشههای ساده حاوی فایلهای rpm. (بدون پیوند نمادین) است.
مخازن در درجه اول با استفاده از URI یا نام مستعار (alias) خود شناسایی میشوند. نام مستعار به عنوان نامی کوتاه برای URI طولانی یا نام مخزن عمل میکند. نام (name) مخزن باید مخزن را بهطور خلاصه توصیف کند و در جدولها و پیامها به کاربر نشان داده میشود. نام الزامی نیست و اگر مشخص نشده باشد، نام مستعار بهجای آن نشان داده میشود. نام مستعار الزامی است و مخزن را بهطور یکتا روی سیستم شناسایی میکند.
میتوان از نام مستعار (alias)، نام (name)، URI، یا شماره (number) برگرفته از فهرست zypper repos برای مشخص کردن یک مخزن به عنوان آرگومان دستورات و گزینههای مختلف زیپر مانند refresh، --repo، یا --from استفاده کرد.
جدا از موارد بالا، مخازن چندین ویژگی دیگر دارند که میتوان آنها را با استفاده از دستورات شرحدادهشده در این بخش زیر تنظیم کرد، یا با ویرایش دستی فایلهای تعریف مخزن (فایلهای .repo، بخش فایلها (FILES) را ببینید).
جایگزینی متغیرها (Variable substitution):
میتوانید از متغیرهای زیر درون مقادیر name و URI در فایلهای .repo یا .service استفاده کنید:
$arch
$basearch
$releasever, $releasever_major, $releasever_minor
این ویژگی برای مخازن مرتبط مانند پکمن (http://ftp.gwdg.de/pub/linux/packman/suse/$releasever) مفید است که باید همیشه با توزیع نصبشده سازگار باشند، حتی پس از ارتقای توزیع.
برای تسهیل انجام ارتقای توزیع، مقدار $releasever را میتوان با ایجاد یک متغیر سفارشی با همین نام (در زیر ببینید) بهطور دائمی روی یک مقدار تعریفشده توسط کاربر تنظیم کرد. به این ترتیب میتوانید به راحتی همه مخازن استفادهکننده از $releasever را به نسخه جدید منتقل کنید (به شرطی که ساختار سرور تغییر نکرده باشد و مخازن جدید از قبل در دسترس باشند).
برای یک دستور تکی زیپر، مقدار $releasever را میتوان با استفاده از گزینه سراسری --releasever بهطور موقت رونویسی کرد.
علاوه بر این، $releasever_major روی بخش ابتدایی تا نقطه اول (بدون احتساب خود نقطه) تنظیم میشود؛ و $releasever_minor روی بخش انتهایی پس از نقطه اول تنظیم خواهد شد. اگر نقطهای در $releasever وجود نداشته باشد، $releasever_major با $releasever برابر خواهد بود و $releasever_minor خالی میماند.
متغیرهای سفارشی (Custom Variables)
به این صورت میتوانید یک متغیر سفارشی، مثلاً $releasever را روی مقدار 99.0 تنظیم کنید:
برای حذف متغیر سفارشی، به سادگی فایل آن را در /etc/zypp/vars.d حذف کنید:
برای بررسی جاهایی که در حال حاضر از $releasever استفاده میکنید، اجرا کنید:
به یاد داشته باشید که هنگام استفاده از این متغیرها در خط فرمان شل، کاراکتر $ را محافظت (escape) کنید:
اگر پس از یک متغیر نویسهای الفبانومریک یا زیرخط بیاید، باید در {} محصور شود:
تعریف مقدار پیشفرض ${variable:-word} و جایگزین ${variable:+word} به سبک بش:
نکته:
قالبهای URI پشتیبانیشده (Supported URI formats):
scheme:@]host[:port]]/path[?query][#fragment]
درایو CD یا DVD
dvd:/subdir?devices=/dev/sr0,/dev/sr1
درخت پوشه FTP/HTTP/HTTPS
تنظیمات صریح پروکسی را میتوان از طریق پارامترهای اختیاری proxy، proxyport، proxyuser و proxypass ارسال کرد.
روشهای احراز هویت HTTP قابل استفاده را میتوان به عنوان یک فهرست جداشده با کاما از طریق پارامتر اختیاری auth تعیین کرد. روشهای معتبر به عنوان مثال شامل basic، digest، ntlm، negotiate هستند. توجه داشته باشید که این فهرست به روشهای پشتیبانیشده توسط کتابخانه curl وابسته است.
رفتار اعتبارسنجی SSL را میتوان با استفاده از گزینه ssl_verify تغییر داد (از این گزینه باید با احتیاط استفاده شود). مقادیر معتبر عبارتند از yes (پیشفرض امن)، host، peer یا no. مقدار Host فقط بررسی میکند که فیلد "Common Name" یا فیلد "Subject Alternate Name" در گواهی سرور با نام میزبان موجود در URL مطابقت داشته باشد. مقدار Peer فقط اصالت گواهی ارائهشده توسط سرور را در برابر زنجیره امضاهای دیجیتال موجود در ssl_capath تایید میکند. مقدار No هیچ بررسی انجام نمیدهد. مقدار Yes پیشفرض امن است که بررسیهای host و peer را با هم انجام میدهد.
برای احراز هویت با گواهی کلاینت SSL، از گزینههای ssl_clientcert برای مشخص کردن مسیر گواهی کلاینت ssl و ssl_clientkey برای مشخص کردن مسیر کلید کلاینت SSL استفاده کنید. از ssl_capath برای تغییر پوشه حاوی گواهیهای CA استفاده کنید (پیشفرض /etc/ssl/certs است).
ftp://user:pass@server/%2fhome/user/path/to/media/dir
http://user:pass@server/path
https://user:pass@server/path?proxy=foo&proxyuser=me&proxypass=pw
https://server/path?ssl_clientcert=/entitlement/1234.pem&ssl_clientkey=/entitlement/1234-key.pem
حجم دیسک (پارتیشن)
درخت پوشه محلی
رسانه در یک تصویر ISO (سوارشده بهصورت loopback)
iso:/?iso=CD1.iso&url=hd:/?device=/dev/hda
iso:/subdir?iso=DVD1.iso&url=nfs://nfs-server/directory&mnt=/nfs/attach/point&filesystem=udf
درخت پوشه به اشتراک گذاشتهشده با NFS
nfs://nfs-server/exported/path?mountoptions=ro&type=nfs4
nfs4://nfs-server/exported/path?mountoptions=ro
درخت پوشه CIFS/SMB
پارامتر اختیاری workgroup یا domain نام workgroup را مشخص میکند. به عنوان جایگزینی برای ارسال username:password در بخش authority نشانی URI، میتوان از پارامترهای user و pass استفاده کرد.
cifs://usern:passw@servername/share/path/on/the/share?mountoptions=ro,noguest
cifs://usern:passw@servername/share/path/on/the/share?workgroup=mygroup
cifs://servername/share/path/on/the/share?user=usern&pass=passw
مخازن سرویس ساخت اوپنسوزه (OBS - OpenSUSE Build Service)
اگر platform حذف شود، از openSUSE_$releasever استفاده میشود مگر اینکه مقداری برای obs.platform در zypper.conf تعریف شده باشد. اگر از openSUSE_Factory یا openSUSE_Tumbleweed پیروی میکنید، ممکن است لازم باشد اینها را به عنوان پلتفرم پیشفرض خود تنظیم کنید. اما ما فقط میتوانیم حدس بزنیم که پوشه حاوی مخزن متناسب با توزیع شما روی سرور چگونه نامگذاری شده است. در صورت شک، باید URL مناسب را در یک مرورگر بررسی کنید.
obs://zypp:Head/openSUSE_Factory
obs://zypp:Head/openSUSE_Factory_Staging_Gcc49_standard
دستورها (Commands):
addrepo (ar) [options] URI alias
addrepo (ar) [options] FILE*.repo*
مخازن تازهافزودهشده به صورت پیشفرض بازخوانی خودکار (auto-refresh) غیرفعال دارند (به جز مخازنی که از یک فایل .repo درونریزی شدهاند که بازخوانی خودکار در آنها فعال است). برای فعالسازی بازخوانی خودکار از addrepo -f یا گزینه --refresh دستور modifyrepo استفاده کنید.
همچنین این دستور مخازن تازهافزودهشده را به طور خودکار بازخوانی نمیکند. مخازن در اولین باری که استفاده شوند بازخوانی خواهند شد، یا میتوانید پس از پایان تغییرات خود با دستورات *repo، از دستور refresh استفاده کنید.
-r, --repo file.repo
-c, --check
-C, --no-check
-n, --name name
-e, --enable
-d, --disable
-f, --refresh
-F, --no-refresh
-p, --priority [1-2147483647]|0
-k, --keep-packages
-K, --no-keep-packages
-g, --gpgcheck
--gpgcheck-strict
--gpgcheck-allow-unsigned
--gpgcheck-allow-unsigned-repo
--gpgcheck-allow-unsigned-package
-G, --no-gpgcheck
غیرفعال کردن بررسیهای GPG توصیه نمیشود. امضای دادهها گیرنده را قادر میسازد بررسی کند که پس از امضای دادهها هیچ تغییری رخ نداده است. پذیرش دادههای بدون امضا، دارای امضای نادرست یا ناشناخته میتواند منجر به آسیبدیدگی سیستم و در موارد حاد حتی به خطر افتادن امنیت سیستم شود.
--default-gpgcheck
مگر اینکه تنظیمات zypp.conf خود را تغییر داده باشید، این همان --gpgcheck است که رفتار آن در بخش GPG checks توصیف شده است.
مثالها:
$ zypper ar -c -n 'Packman 11.1 repo' http://packman.iu-bremen.de/suse/11.1 packman
$ zypper ar https://download.opensuse.org/repositories/zypp:/svn/openSUSE_Factory/zypp:svn.repo
$ zypper ar myreposbackup.repo
removerepo (rr) [options] alias|name|#|URI...
--loose-auth
--loose-query
-a, --all
-l, --local
-t, --remote
-m, --medium-type type
repos (lr) [options] [repo]...
دادههای زیر میتوانند برای هر مخزن یافتشده در سیستم چاپ شوند: # (شماره مخزن)، Alias (شناسه یکتا)، Name (نام)، Enabled (آیا مخزن فعال است یا خیر)، GPG Check (آیا بررسی GPG برای متاداده مخزن (r) یا بستههای rpm بارگیریشده (p) فعال است یا خیر)، Refresh (آیا بازخوانی خودکار برای مخزن فعال است یا خیر)، Priority (اولویت)، Type (نوع متاداده مخزن: rpm-md، yast2، plaindir). اینکه کدام دادهها نمایش داده شوند توسط گزینههای خط فرمان فهرستشده در زیر و تنظیم main.repoListColumns در zypper.conf تعیین میشود. به طور پیشفرض، #، Alias، Name، Enabled، GPG Check و Refresh نمایش داده میشوند.
شماره مخزن یک شناسه یکتا از مخزن در مجموعه فعلی مخازن است. اگر مخزنی را اضافه، حذف یا تغییر دهید، ممکن است شمارهها تغییر کنند. هنگام استفاده از شمارهها همراه با دستورات مدیریت مخزن، این نکته را در نظر داشته باشید. از سوی دیگر، استفاده از نام مستعار به جای شماره همواره ایمن است.
برای نمایش اطلاعات تفصیلی درباره مخازن خاص، آنها را به عنوان آرگومان مشخص کنید، چه با نام مستعار، نام، شماره حاصل از zypper lr ساده، یا با URI؛ مانند zypper lr factory یا zypper lr 2.
-e, --export FILE.repo|-
-a, --alias
-n, --name
-u, --uri
-p, --priority
-r, --refresh
-k, --keep-packages
-d, --details
-E, --show-enabled-only
-U, --sort-by-uri
-P, --sort-by-priority
-A, --sort-by-alias
-N, --sort-by-name
مثالها:
$ zypper repos -e myreposbackup.repo
$ zypper lr -pu
renamerepo (nr) alias|name|#|URI new-alias
مثالها:
$ zypper nr 8 myrepo
modifyrepo (mr) options alias|name|#|URI...
modifyrepo (mr) options --all|--remote|--local|--medium-type
-n, --name name
-e, --enable
-d, --disable
-f, --refresh (legacy: -r)
-F, --no-refresh (legacy: -R)
-p, --priority [1-2147483647]|0
-k, --keep-packages
-K, --no-keep-packages
-g, --gpgcheck
--gpgcheck-strict
--gpgcheck-allow-unsigned
--gpgcheck-allow-unsigned-repo
--gpgcheck-allow-unsigned-package
-G, --no-gpgcheck
غیرفعال کردن بررسیهای GPG توصیه نمیشود. امضای دادهها گیرنده را قادر میسازد بررسی کند که پس از امضای دادهها هیچ تغییری رخ نداده است. پذیرش دادههای بدون امضا، دارای امضای نادرست یا ناشناخته میتواند منجر به آسیبدیدگی سیستم و در موارد حاد حتی به خطر افتادن امنیت سیستم شود.
--default-gpgcheck
مگر اینکه تنظیمات zypp.conf خود را تغییر داده باشید، این همان --gpgcheck است که رفتار آن در بخش GPG checks توصیف شده است.
-a, --all
-l, --local
-t, --remote
-m, --medium-type type
مثالها:
$ zypper mr -kt
$ zypper mr -er updates
$ zypper mr -da
refresh (ref) [alias|name|#|URI]...
-f, --force
-b, --force-build
-d, --force-download
-B, --build-only
-D, --download-only
--include-all-archs
-s, --services
clean (cc) [options] [alias|name|#|URI]...
-m, --metadata
-M, --raw-metadata
-a, --all
مدیریت سرویس (Service Management)
دستورات services، addservice، removeservice، modifyservice و refresh-services برای مدیریت و دستکاری سرویسها به کار میروند. یک سرویس توسط URI خود مشخص میشود و باید یک نام مستعار یکتا (در بین هم سرویسها و هم مخازن) برای آن تعریف شده باشد.
با مخازن مستقل (که متعلق به هیچ سرویسی نیستند) نیز مانند سرویسها رفتار میشود. دستور ls آنها را فهرست میکند، دستور ms آنها را تغییر میدهد و غیره. البته گزینههای مختص مخزن، مانند --keep-packages در اینجا در دسترس نیستند. برای دستکاری آنها میتوانید از دستورات مدیریت مخزن استفاده کنید.
addservice (as) [options] URI alias
سرویسهای تازهافزودهشده به طور خودکار بازخوانی نمیشوند. برای بازخوانی آنها از دستور refresh-services استفاده کنید. زیپر هنگام افزودن سرویس به URI سرویس دسترسی پیدا نمیکند، بنابراین نوع سرویس تا زمانی که بازخوانی نشود، نامشخص خواهد بود.
-n, --name name
-e, --enable
-d, --disable
-f, --refresh
-F, --no-refresh
removeservice (rs) [options] alias|name|#|URI...
--loose-auth
--loose-query
modifyservice (ms) options alias|name|#|URI
modifyservice (ms) options --all|--remote|--local|--medium-type
گزینههای عمومی (Common Options)
-n, --name name
-e, --enable
-d, --disable
-f, --refresh (legacy: -r)
-F, --no-refresh (legacy: -R)
-a, --all
-l, --local
-t, --remote
-m, --medium-type type
گزینههای خاص سرویس RIS (RIS Service Specific Options)
-i, --ar-to-enable alias
-I, --ar-to-disable alias
-j, --rr-to-enable alias
-J, --rr-to-disable alias
-k, --cl-to-enable
-K, --cl-to-disable
services (ls) [options]
-u, --uri
-p, --priority
-d, --details
-r, --with-repos
-P, --sort-by-priority
-E, --show-enabled-only
-U, --sort-by-uri
-N, --sort-by-name
refresh-services (refs) [options] alias|name|#|URI...
سرویسهای RIS بر اساس محتوای فعلی نمایه مخزن، مخازنی را به سیستم شما اضافه، حذف یا ویرایش میکنند. با این حال، تفاوت در وضعیت فعال/غیرفعال ناشی از فراخوانی دستی modify-repo روی یک مخزن سرویس بازگردانده نخواهد شد، مگر اینکه از گزینه --restore-status استفاده شود یا نمایه مخزن صریحاً این تغییر را درخواست کند.
سرویسها فقط مخازن تعریفشده را مدیریت میکنند و آنها را بازخوانی نمیکنند. برای بازخوانی مخازن نیز، از گزینه --with-repos یا دستور refresh استفاده کنید.
-f, --force
-r, --with-repos
-R, --restore-status
مدیریت قفل بستهها (Package Locks Management)
قفل بستهها با هدف جلوگیری از اعمال تغییرات در مجموعه بستههای نصبشده روی سیستم به کار میروند. قفلها به عنوان پرسوجوها در فایل /etc/zypp/locks ذخیره میشوند (همچنین locks(5) را ببینید). بستههای منطبق با پرسوجو از تغییر وضعیت نصب خود منع میشوند؛ یک بسته نصبشده نمیتواند حذف یا ارتقا داده شود و یک بسته نصبنشده نمیتواند نصب گردد. هنگام درخواست برای نصب، ارتقا یا حذف چنین بسته قفلشدهای، کادر گفتگوی مشکل وابستگی دریافت خواهید کرد.
یک lock-spec به صورت "NAME [OP EDITION]" تشکیل میشود، که در آن NAME همچنین میتواند یک الگوی جستجوی چندگانه (glob) با استفاده از نویسههای عمومی * و ? باشد. انواع غیربستهای ممکن است رشته نوع آنها در ابتدا درج شود (مانند patch:foo یا product:baa) یا از گزینه --type دستورات استفاده کنند.
فرم پایه همه نسخههای موارد منطبق را قفل خواهد کرد. میتوانید در صورت تمایل قفل را محدود کنید تا با نسخه خاص یا دامنهای از نسخهها با استفاده از =، <، <=، >، >= یا != پس از نسخه مطابقت داشته باشد.
نکته (Note)
اگر در اطراف عملگر از فاصله خالی استفاده میکنید، باید بر اساس قوانین پوستهای (shell) که استفاده میکنید، رشته را در گیومه قرار داده یا فاصلهها را اسکیپ کنید.
locks (ll)
-m, --matches
-s, --solvables
addlock (al) [options] lock-spec...
-r, --repo alias|name|#|URI
-t, --type type
-m, --comment comment
removelock (rl) [options] lock-number|lock-spec...
-r, --repo alias|name|#|URI
-t, --type type
cleanlocks (cl)
این دستور قفلهایی را جستجو میکند که در حال حاضر (با توجه به مخازن استفادهشده) هیچ بستهای را قفل نمیکنند و برای هر یک از این قفلها از کاربر میپرسد که آیا آن را حذف کند یا خیر.
مدیریت محلیسازی (Locale Management)
این دستورات اطلاعاتی درباره محلیسازیهای درخواستی ارائه داده و امکان مدیریت آنها را فراهم میکنند. یک محلیسازی با یک کد زبان تعریف میشود. برای بسیاری از بستهها، بستههای وابسته به محلیسازی موجود هستند که ترجمهها یا فرهنگهای لغت را ارائه میدهند. برای نصب شدن این موارد، محلیسازی زبان مورد نظر باید توسط کتابخانه مدیر بسته به عنوان درخواستی علامتگذاری شود.
locales (lloc) [OPTIONS] [LOCALE] ...
-a, --all
-p, --packages
addlocale (aloc) [OPTIONS] <LOCALE> ...
-n, --no-packages
removelocale (rloc) [OPTIONS] <LOCALE> ...
-n, --no-packages
مثالها:
$ zypper locales
$ zypper locales --packages de en
$ zypper locales en_
$ zypper locales en*
$ zypper aloc --packages de_CH
سایر دستورات (Other Commands)
system-architecture
versioncmp (vcmp) VERSION1 VERSION2
خروجی پیشفرض به صورت خوانا برای انسان است. اگر از گزینه سراسری --terse استفاده شود، نتیجه یک عدد صحیح خواهد بود؛ در صورتی که VERSION1 از VERSION2 قدیمیتر/جدیدتر باشد منفی/مثبت، و در صورت مطابقت صفر است.
-m, --match
برای مثال:
$ zypper vcmp -m 0.15.3 0.15.3-2
$ zypper vcmp 0.15.3 0.15.3-2
targetos (tos)
اگر baseproduct این مدخل را ارائه ندهد، یا اگر اصلاً هیچ baseproductای نصب نشده باشد، در صورت استفاده از گزینه سراسری --terse، مقدار خالی خواهد بود.
در حالت غیر terse، اگر یک baseproduct نصب شده باشد، برچسب توزیع به جای مقدار خالی نشان داده میشود.
-l, --label
licenses
ابتدا فهرستی از تمام بستهها و مجوزها و/یا EULAهای آنها نمایش داده میشود. به دنبال آن خلاصهای شامل تعداد کل بستههای نصبشده و تعداد بستههای نصبشده دارای EULA که نیازمند تأیید کاربر بودند ارائه میشود. از آنجا که EULAها روی سیستم ذخیره نمیشوند و تنها از طریق متاداده مخزن قابل خواندن هستند، این خلاصه همچنین شامل تعداد بستههای نصبشدهای است که معادل آنها در مخازن وجود دارد. این گزارش با فهرستی از تمامی مجوزهای مورد استفاده توسط بستههای نصبشده پایان مییابد.
این دستور میتواند برای شرکتهایی که یک توزیع سفارشی (مانند applianceها) را بازتوزیع میکنند مفید باشد تا متوجه شوند به چه مجوزهایی پایبند هستند.
download [OPTIONS]
به طور پیشفرض بستهها در کش بسته libzypp بارگیری میشوند (/var/cache/zypp/packages؛ برای کاربران غیر ریشه $XDG_CACHE_HOME/zypp/packages)، اما میتوان این مسیر را با استفاده از گزینه سراسری --pkg-cache-dir تغییر داد.
خروجی قابل تجزیه XML تولیدشده توسط zypper --xmlout شامل یک گره <download-result> برای هر بستهای خواهد بود که زیپر سعی در بارگیری آن داشته است. در صورت موفقیت، مکان بسته بارگیریشده در صفت path زیرگره <localfile> یافت میشود (مسیر xpath: download-result/localpath@path):
<download-result>
<solvable>
<kind>package</kind>
<name>zypper</name>
<edition epoch="0" version="1.9.17" release="26.1"/>
<arch>x86_64</arch>
<repository name="repo-oss-update (13.1)" alias="openSUSE:repo-oss-update"/>
</solvable>
<localfile path="/var/cache/zypp/pac.../zypper-1.9.17-26.1.x86_64.rpm"/>
</download-result>
--all-matches
--dry-run
-r, --repo alias|name|#|URI
--from alias|name|#|URI
source-download [OPTIONS]
-d, --directory dir
--delete
--no-delete
--status
ps [OPTIONS]
PID
PPID
UID
Login
Command
Service
Files
-s, --short
--print format
-d, --debugFile filename
مثالها:
$ zypper ps -ss
$ zypper ps -sss
$ zypper ps --print "systemctl status %s"
needs-rebooting
فلگ reboot-needed زمانی تنظیم میشود که بستهای که installhint(reboot-needed) را فراهم میکند، بهروزرسانی یا نصب شود. علاوه بر این، یک فهرست از پیشتعریفشده (/etc/zypp/needreboot) از بستههای شناختهشده وجود دارد که باعث تنظیم بدون قید و شرط فلگ reboot-needed میشوند. کد خروج ZYPPER_EXIT_INF_REBOOT_NEEDED نشان میدهد که راهاندازی مجدد پیشنهاد میشود، در غیر این صورت کد خروج روی ZYPPER_EXIT_OK تنظیم میگردد.
به اسکریپتها توصیه میشود از این دستور برای آزمایش اینکه آیا راهاندازی مجدد سیستم پیشنهاد شده است استفاده کنند. از --quiet برای جلوگیری از نمایش خروجی عادی استفاده کنید.
زیردستورها (Subcommands)
subcommand
گزینههای سراسری (GLOBAL OPTIONS)
-h, --help
-V, --version
-c, --config file
ترتیب اولویت با --config به صورت زیر است:
نکته
استفاده و مکان فایل سراسری سیستم /etc/zypp/zypp.conf را نمیتوان به این روش تغییر داد. این فایل صرفاً از این جهت در اینجا ذکر شده که برخی از گزینههای خط فرمان زیپر امکان بازنویسی پیشفرضهای سراسری سیستم تعریفشده در zypp.conf را فراهم میکنند.
همچنین برای اطلاعات بیشتر بخش فایلها (FILES) را ببینید.
-v, --verbose
-q, --quiet
--color, --no-color
-A, --no-abbrev
-t, --terse
-s, --table-style integer
-n, --non-interactive
--non-interactive-include-reboot-patches
-x, --xmlout
-i, --ignore-unknown
برای دستورات search و info این گزینه باعث میشود که اگر پرسوجو هیچ تطابقی پیدا نکرد، زیپر به جای ZYPPER_EXIT_INF_CAP_NOT_FOUND مقدار ZYPPER_EXIT_OK را برگرداند.
-D, --reposd-dir dir
--servicesd-dir dir
-C, --cache-dir dir
--raw-cache-dir dir
--solv-cache-dir dir
--pkg-cache-dir dir
--userdata string
گزینههای مخزن:
--no-gpg-checks
--gpg-auto-import-keys
-p, --plus-repo URI
--plus-content tag
اگر متادادههای یک مخزن غیرفعال در کش محلی موجود نباشد، برای یافتن کلیدواژههای منطبق بارگیری خواهند شد. در غیر این صورت، اسکن کلیدواژه از متادادههای موجود در کش محلی استفاده خواهد کرد. تنها در صورتی که همراه با دستور refresh استفاده شود، اسکن کلیدواژه تمام مخازن غیرفعال را تازهسازی خواهد کرد.
برای تازهسازی متاداده تمام مخازن غیرفعال:
برای گنجاندن مخزن غیرفعال repo-debug در یک جستجو:
برای جستجو فقط در مخزن غیرفعال repo-debug:
برای فعال کردن تمام مخازنی که کلیدواژه debug را ارائه میدهند:
--disable-repositories
--no-refresh
--no-cd
--no-remote
--releasever version
برای بررسی اینکه هماکنون در کجا از $releasever استفاده میکنید، دستور زیر را اجرا کنید:
گزینههای مقصد:
-R, --root dir
--installroot dir
--disable-system-resolvables
زیردستورها (SUBCOMMANDS)
زیردستورهای زیپر از git(1) الهام گرفته شدهاند. زیردستورها برنامههای اجرایی مستقلی هستند که در دایرکتوری zypper_execdir (/usr/lib/zypper/commands) قرار دارند. برای زیردستورها، زیپر یک پوشش (wrapper) فراهم میکند که مکان زیردستورها را میداند و آنها را با ارسال گزینهها و آرگومانهای دستور اجرا میکند. اگر زیردستوری در zypper_execdir پیدا نشود، پوشش در بقیه مسیرهای موجود در $PATH شما به دنبال آن خواهد گشت. بنابراین، نوشتن افزونههای محلی زیپر که در فضای سیستمی نیستند امکانپذیر است. این قابلیت را میتوان با تنظیم "subcommand.seachSubcommandInPath" روی "no" در فایل zypper.conf غیرفعال کرد.
نحوه افزودن زیردستور خودتان به شکل zypper mytask به این صورت است:
میتوانید از دستور توکار zypper subcommand برای دریافت فهرستی از تمام زیردستورها در zypper_execdir و سایر مکانهای موجود در $PATH خود استفاده کنید.
استفاده از گزینههای سراسری زیپر همراه با زیردستورها، و همچنین اجرای زیردستورها در zypper shell در حال حاضر پشتیبانی نمیشود.
فایلها (FILES)
/etc/zypp/zypper.conf, $HOME/.zypper.conf
تنظیمات کاربر بر تنظیمات سراسری ترجیح داده میشوند. به طور مشابه، گزینههای خط فرمان بر تنظیمات هر یک از این فایلها برتری دارند. به طور خلاصه، ترتیب اولویت به صورت زیر است (از بیشترین به کمترین):
برای فهرستی از گزینههای موجود و توضیحات آنها، توضیحات درون /etc/zypp/zypper.conf را ببینید.
نکته
فایل سراسری سیستم /etc/zypp/zypp.conf صرفاً از این جهت در اینجا ذکر شده که برخی از گزینههای خط فرمان زیپر امکان بازنویسی پیشفرضهای سراسری سیستم تعریفشده در آن را میدهند. فایلهای zypp.conf و zypper.conf محتوای متفاوتی دارند و اهداف متفاوتی را دنبال میکنند.
/etc/zypp/zypp.conf
/etc/zypp/locks
این فایل توسط تمامی برنامههای مبتنی بر ZYpp استفاده میشود.
/etc/zypp/repos.d
میتوانید از گزینه سراسری --reposd-dir برای استفاده از یک دایرکتوری جایگزین برای این منظور یا از گزینه --root برای نسبی کردن این دایرکتوری به دایرکتوری ریشه مشخصشده استفاده کنید.
این دایرکتوری توسط تمامی برنامههای مبتنی بر ZYpp استفاده میشود.
/etc/zypp/services.d
میتوانید از گزینه سراسری --servicesd-dir برای استفاده از یک دایرکتوری جایگزین برای این منظور یا از گزینه --root برای نسبی کردن این دایرکتوری به دایرکتوری ریشه مشخصشده استفاده کنید.
این دایرکتوری توسط تمامی برنامههای مبتنی بر ZYpp استفاده میشود.
/usr/lib/zypper/commands
/var/cache/zypp/raw
این دایرکتوری توسط تمامی برنامههای مبتنی بر ZYpp استفاده میشود.
/var/cache/zypp/solv
این دایرکتوری توسط تمامی برنامههای مبتنی بر ZYpp استفاده میشود.
/var/cache/zypp/packages
زیردایرکتوریهای مخازن حذفشده یا ناشناخته به طور خودکار پاکسازی میشوند. با ایجاد فایلی با نام .no_auto_prune در دایرکتوری pkg-cache میتوان از این پاکسازی خودکار جلوگیری کرد.
ایجاد یک فایل .keep_packages در دایرکتوری pkg-cache، بستههای بارگیریشده را برای تمام مخازن کششده در اینجا نگه میدارد و ویژگی keep-packages مخازن را نادیده میگیرد و بازنویسی میکند.
همچنین برای پاکسازی این دایرکتوریهای کش، دستور clean را ببینید.
این دایرکتوری توسط تمامی برنامههای مبتنی بر ZYpp استفاده میشود.
/var/log/zypper.log
/var/log/zypper.solverTestCase
/var/log/updateTestcase-YYYY-MM-DD-hh-mm-ss
/var/log/zypp/history
~/.zypper_history
/etc/zypp/needreboot
/etc/zypp/needreboot.d
کدهای خروج (EXIT CODES)
چندین کد خروج برای دستورات توکار زیپر جهت استفاده مثلاً در اسکریپتها تعریف شده است. این کدها در فایل هدر src/zypper-main.h در بسته سورس زیپر تعریف شدهاند. کدهای زیر 100 نشاندهنده خطا هستند، کدهای بالای 100 اطلاعات خاصی ارائه میدهند، و 0 نشاندهنده اجرای موفق و عادی است. در ادامه فهرستی از این کدها به همراه توضیحات آمده است:
0 - ZYPPER_EXIT_OK
1 - ZYPPER_EXIT_ERR_BUG
2 - ZYPPER_EXIT_ERR_SYNTAX
3 - ZYPPER_EXIT_ERR_INVALID_ARGS
4 - ZYPPER_EXIT_ERR_ZYPP
5 - ZYPPER_EXIT_ERR_PRIVILEGES
6 - ZYPPER_EXIT_NO_REPOS
7 - ZYPPER_EXIT_ZYPP_LOCKED
8 - ZYPPER_EXIT_ERR_COMMIT
100 - ZYPPER_EXIT_INF_UPDATE_NEEDED
101 - ZYPPER_EXIT_INF_SEC_UPDATE_NEEDED
102 - ZYPPER_EXIT_INF_REBOOT_NEEDED
قدیمی: پس از نصب موفقیتآمیز وصلهای که نیازمند راهاندازی مجدد کامپیوتر است برگردانده میشود. این رفتار قدیمی حفظ شده است، اما عیب آن این است که فقط وصلهها را در بر میگیرد نه بستهها را. دستور جدید needs-rebooting روش توصیهشده برای آزمایش این است که آیا راهاندازی مجدد سیستم پیشنهاد میشود یا خیر.
103 - ZYPPER_EXIT_INF_RESTART_NEEDED
104 - ZYPPER_EXIT_INF_CAP_NOT_FOUND
105 - ZYPPER_EXIT_ON_SIGNAL
106 - ZYPPER_EXIT_INF_REPOS_SKIPPED
107 - ZYPPER_EXIT_INF_RPM_SCRIPT_FAILED
زیردستورهای زیپر (بخش زیردستورها (SUBCOMMANDS) را ببینید) ممکن است کدهای متفاوتی را برگردانند که باید در صفحه راهنمای دستورات شرح داده شوند. برای مشاهده صفحه راهنمای زیردستور در صورت ارائه شدن، zypper help subcommand را فراخوانی کنید.
صفحه خانگی (HOMEPAGE)
نویسندگان (AUTHORS)
پروژه زیپر توسط مارتین ویدنر (Martin Vidner)، یان کوپک (Jan Kupec)، مایکل آندرس (Michael Andres)، دانکن مکویار پرت (Duncan Mac-Vicar Prett)، جوزف ریدینگر (Josef Reidinger) و استانیسلاو ویشنوفسکی (Stanislav Visnovsky) آغاز شد. افراد بسیاری بعداً در آن مشارکت کردند.
همچنین ببینید (SEE ALSO)
locks(5), zypper-log(8), YaST2(8)
| 2026-09-04 | SUSE Linux |