REPREPRO(1) REPREPRO REPREPRO(1)

reprepro - ایجاد، مدیریت و همگام‌سازی مخزن محلی بسته‌های دبیان

reprepro --help

reprepro [ گزینه‌ها ] دستور [ آرگومان‌های-مخصوص-دستور ]

دستور reprepro ابزاری برای مدیریت مخزن بسته‌های دبیان (.deb، .udeb، .dsc، ...) است. این ابزار فایل‌هایی را که به صورت دستی تزریق شده‌اند یا از مخزن دیگری که (به طور جزئی) آینه‌سازی شده دانلود شده‌اند، درون سلسله‌مراتب pool/ ذخیره می‌کند. بسته‌های مدیریت‌شده و مجموع‌های مقابله‌ای (checksum) فایل‌ها در یک فایل پایگاه داده Berkeley DB ذخیره می‌شوند؛ بنابراین به سرور پایگاه داده نیازی نیست. بررسی امضای مخازن آینه‌شده و ساخت امضا برای نمایه بسته‌های تولیدشده نیز پشتیبانی می‌شود.

نام کاری پیشین این برنامه mirrorer بوده است.

گزینه‌ها را می‌توان پیش از دستور مشخص کرد. هر یک از آن‌ها بر زیرمجموعه متفاوتی از دستورها اثر می‌گذارد و توسط سایر دستورها نادیده گرفته می‌شود.

فهرست کوتاهی از گزینه‌ها و دستورها را همراه با توضیحات نمایش می‌دهد.
خروجی پرحرف‌تر (مشروح‌تر). این گزینه را می‌توان چندین بار اعمال کرد. یک -V بزرگ به اندازه پنج -v کوچک به حساب می‌آید.
کاهش جزئیات خروجی (کم‌حرف‌تر). می‌توان آن را چندین بار اعمال کرد. یک -v و یک -s اثر یکدیگر را خنثی می‌کنند.
این گزینه نادیده گرفته می‌شود، زیرا دیگر وجود ندارد.
دایرکتوری پایه‌ای را تعیین می‌کند که سایر دایرکتوری‌های پیش‌فرض نسبت به آن سنجیده می‌شوند. اگر مقداری مشخص نشود و متغیر محیطی REPREPRO_BASE_DIR نیز تنظیم نشده باشد، از دایرکتوری جاری استفاده خواهد شد.
دایرکتوری پایه مخزن تحت مدیریت را مشخص می‌کند؛ یعنی جایی که زیردایرکتوری pool/ در آن قرار دارد، و دایرکتوری dists/ به طور پیش‌فرض درون آن جای می‌گیرد. اگر با '+b/' آغاز شود، نسبت به basedir سنجیده می‌شود.

مقدار پیش‌فرض برای این گزینه basedir است.

دایرکتوری محل جستجوی پیکربندی را تعیین می‌کند.

اگر با '+b/' آغاز شود، نسبت به basedir خواهد بود.

اگر مقداری داده نشود، از +b/conf (یعنی basedir/conf) استفاده خواهد شد.

دایرکتوری تولید فایل‌های نمایه را مشخص می‌کند (مانند Packages.gz، Sources.gz و Release.gpg).

اگر با '+b/' آغاز شود نسبت به basedir، و اگر با '+o/' آغاز شود نسبت به outdir در نظر گرفته می‌شود.

در صورت مشخص نشدن، مقدار +o/dists (یعنی outdir/dists) استفاده می‌شود.

نکته: نام dists در apt به صورت هاردکد تعبیه شده است؛ بنابراین این گزینه اغلب تنها برای آزمایش یا زمانی کاربرد دارد که وب‌سرور شما ساختار دایرکتوری متفاوتی را نسبت به چینش فیزیکی فایل‌ها وانمود می‌کند.

هشدار: هنگام تغییر مکرر این گزینه بین دو مقداری که به یک دایرکتوری یکسان ختم نمی‌شوند، مراقب باشید. برنامه reprepro تنها بررسی می‌کند که آیا فایل‌های مورد نیازش وجود دارند یا خیر. اگر محتوا تغییری نکرده باشد و فایل وجود داشته باشد، به آن دست نخواهد زد؛ با این فرض که این همان فایلی است که دفعه قبل نوشته شده است (و فرض بر این است که هر --distdir متفاوت به همان دایرکتوری ختم می‌شده است). بنابراین یا دایرکتوری را پیش از تنظیم --distdir به آن پاک‌سازی کنید، یا ابتدا یک بار export را با دایرکتوری جدید اجرا نمایید تا وضعیت پایداری داشته باشید.

دایرکتوری محل ذخیره فایل‌های ایجادشده توسط دستورالعمل Log: در صورتی که مسیر مطلق نداشته باشند.

اگر با '+b/' آغاز شود نسبت به basedir، با '+o/' نسبت به outdir و با '+c/' نسبت به confdir محاسبه می‌شود.

در صورت مشخص نشدن، +b/logs (یعنی basedir/logs) به کار می‌رود.

دایرکتوری محل نگهداری پایگاه‌های داده reprepro را تعیین می‌کند.

اگر با '+b/' آغاز شود نسبت به basedir، با '+o/' نسبت به outdir و با '+c/' نسبت به confdir محاسبه می‌شود.

در صورت مشخص نشدن، +b/db (یعنی basedir/db) استفاده می‌شود.

نکته: این داده‌ها دائمی هستند و حافظه موقت (کَش) نیستند. در صورت از دست رفتن آن‌ها، بازتولید تقریباً کل مخزن الزامی خواهد بود.

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

اگر با '+b/' آغاز شود نسبت به basedir، با '+o/' نسبت به outdir و با '+c/' نسبت به confdir سنجیده می‌شود.

در صورت مشخص نشدن، +b/lists (یعنی basedir/lists) استفاده خواهد شد.

فایل‌های حذف‌شده از pool در morguedir ذخیره می‌شوند.

اگر با '+b/' آغاز شود نسبت به basedir، با '+o/' نسبت به outdir و با '+c/' نسبت به confdir خواهد بود.

در صورت مشخص نشدن، فایل‌های حذف‌شده کاملاً پاک می‌شوند.

هنگام وارد کردن بسته‌ها از مخازن دیگر، به جای /usr/lib/apt/methods در methoddir به دنبال متدهای فراخوانی بگرد.
دستور مشخص‌شده را تنها به این مؤلفه‌ها محدود می‌کند. بسته به دستور مورد نظر، این گزینه بسته‌های اضافه‌شده را به این مؤلفه‌ها محدود می‌سازد، حذف بسته‌ها را به این مؤلفه‌ها منحصر می‌کند، تنها بسته‌های موجود در این مؤلفه‌ها را فهرست می‌کند، و/یا صرفاً بسته‌های این مؤلفه‌ها را بررسی می‌نماید.

مؤلفه‌های چندگانه با جدا کردن آن‌ها به وسیله | مشخص می‌شوند، مانند -C 'main|contrib'.

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

معماری‌های چندگانه با استفاده از نویسه | از هم جدا می‌شوند، مانند -A 'sparc|i386'.

توجه داشته باشید که بسته‌های با معماری all می‌توانند در هر معماری گنجانده شوند اما پس از آن به طور جداگانه مدیریت می‌شوند. بنابراین با استفاده از -A به شیوه‌ای خاص، می‌توان نسخه‌های متفاوتی از یک بسته با معماری all را در معماری‌های مختلف از یک توزیع یکسان نگهداری کرد.

دستور مشخص‌شده را تنها به این نوع بسته‌ها محدود می‌کند (یعنی فقط چنین بسته‌هایی را فهرست کند، فقط چنین بسته‌هایی را حذف کند، فقط چنین بسته‌هایی را وارد کند، و غیره).
بخش (section) موارد واردشده را بازنویسی می‌کند (همچنین فایل‌های override احتمالی را نادیده می‌گیرد).
اولویت (priority) موارد واردشده را بازنویسی می‌کند (همچنین فایل‌های override احتمالی را نادیده می‌گیرد).
این گزینه مشخص می‌کند که آیا و چگونه اقدامات سطح بالا (مانند install، update، pull، delete) باید فایل‌های نمایه توزیع‌هایی را که با آن‌ها کار می‌کنند برون‌ریزی نمایند.
در این حالت، هر توزیعی که اقدام مورد نظر به آن پرداخته است برون‌ریزی خواهد شد، مگر آنکه خطایی رخ داده باشد که احتمالاً باعث خرابی آن شده باشد.
توجه داشته باشید که فقط فایل‌های ناموجود و فایل‌هایی که محتوای مورد نظر آن‌ها بین قبل و بعد از اقدام تغییر کرده است، نوشته خواهند شد. برای دریافت یک برون‌ریزی قطعی و به‌روز، از اقدام export استفاده کنید.
به منظور سازگاری با نسخه‌های پیشین، مقدار lookedat با نام قدیمی normal نیز در دسترس است. نام normal منسوخ شده و در نسخه‌های آینده حذف خواهد شد..TP --export=changed در این حالت، هر توزیعی که واقعاً تغییر کرده باشد صادر (export) خواهد شد، مگر اینکه خطایی رخ داده باشد که احتمالاً باعث خرابی آن شده باشد. (یعنی اگر چیزی تغییر نکرده باشد، حتی فایل‌های ناموجود نیز ایجاد نخواهند شد.)
توجه داشته باشید که فقط فایل‌های ناموجود و فایل‌هایی که محتوای موردنظر آن‌ها بین قبل و بعد از عملیات تغییر کرده است، نوشته خواهند شد. برای داشتن یک صادرات به‌روز و تضمین‌شده، از عملیات export استفاده کنید.
همیشه تمام توزیع‌های بررسی‌شده را صادر می‌کند، حتی اگر خطایی رخ داده باشد که احتمالاً آن را به یک وضعیت ناپایدار و ناهماهنگ کشانده باشد.
هیچ فایل شاخصی (index file) صادر نمی‌شود. باید بعداً export را فراخوانی کنید.
توجه داشته باشید که اگر نمی‌خواهید برخی از فایل‌هایی که فایل‌های شاخصِ دست‌نخورده به آن‌ها اشاره می‌کنند حذف شوند، احتمالاً علاوه بر این به گزینهٔ --keepunreferencedfiles نیز نیاز خواهید داشت.
مانند never است، اما بیشتر خروجی‌های مربوط به آن را فرومی‌نشاند (بی‌صدا می‌کند).
خطاهای از نوع what را نادیده می‌گیرد. برای مقادیر ممکن، بخش ERROR IGNORING را ببینید.
هنگام اجرای update، checkupdate یا predelete، هیچ فایل شاخص یا Release را بارگیری نمی‌کند. این گزینه به‌ندرت مفید است مگر زمانی که تازه یکی از این دستورها را برای همان توزیع‌ها اجرا کرده باشید. و حتی در آن حالت نیز reprepro معمولاً کار خود را به‌خوبی انجام می‌دهد و به‌جز فایل‌های Release و Release.gpg، فایل‌های دیگر را دوباره بارگیری نمی‌کند.
اگر هیچ کاری انجام نشد، به‌جای کد خروج معمول 0، با کد خروج 1 بازگردد.

توجه داشته باشید که منظور از «هیچ کاری انجام نشد»، هدف اصلی عملیات مورد نظر است. عملیات کمکی (باز کردن و بستن پایگاه‌داده، صادر کردن فایل‌های ناموجود با --export=lookedat و ...) معمولاً به‌حساب نمی‌آیند. همچنین توجه داشته باشید که این گزینه چندان خوب آزمایش نشده است. اگر عملیاتی یافتید که در مواردی ادعا می‌کند کاری انجام داده است در حالی که فکر می‌کنید نباید چنین باشد، لطفاً گزارش دهید.

هنگامی که صادرات یک توزیع با شکست مواجه می‌شود، فایل‌های موقت .new را حذف نمی‌کند. (reprepro ابتدا فایل‌های .new را در دایرکتوری dists ایجاد می‌کند و تنها در صورتی که همه چیز تولید شد، تمام فایل‌ها به‌یک‌باره در جایگاه نهایی خود قرار می‌گیرند. اگر این گزینه مشخص نشود و خطایی رخ دهد، همهٔ آن‌ها حذف می‌شوند تا dists تمیز بماند).
فایل‌هایی را که دیگر استفاده نمی‌شوند به این دلیل که بستهٔ مربوط به آن‌ها از آخرین توزیعی که در آن حضور داشته حذف شده یا با نسخهٔ جدیدتری جایگزین شده است، حذف نمی‌کند.
دستورهای include،‏ includedsc،‏ includedeb و processincoming به‌طور پیش‌فرض هر فایلی را که به مخزن (pool) اضافه کرده‌اند و در پایان عملیات علامت استفاده‌شده روی آن نخورده است، حذف می‌کنند. اگرچه این کار pool را تمیز نگه می‌دارد و امکان اعمال تغییرات قبل از تلاش مجدد برای افزودن را فراهم می‌سازد، اما مستلزم کپی کردن و محاسبهٔ جمع‌آزمای (checksum) در هر بار تلاش برای افزودن فایل است.
پس از حذف فایل‌ها یا دایرکتوری‌ها، تلاشی برای حذف دایرکتوری‌های والد با rmdir نمی‌کند. (اگر دایرکتوری‌های شما مجوزهای خاصی دارند که می‌خواهید حفظ شوند، نمی‌خواهید با هشدارهای مربوط به خطاهای حذف آن‌ها آزار ببینید، یا فراخوانی rmdir شما دارای باگی است که دایرکتوری‌های غیرخالی را حذف می‌کند، از این گزینه استفاده کنید.)
هنگام امضا کردن مواردی که به عبارت عبور نیاز دارند، آن را درخواست می‌کند. این یک پیاده‌سازی سریع، ناامن و کثیف با استفاده از تابع منسوخ‌شدهٔ getpass(3) و توضیحات ارائه‌شده توسط gpgme است. بنابراین اعلانات (prompt) ظاهری عجیب خواهند داشت و پشتیبانی از عبارت‌های عبور بیش از ۸ نویسه به libc شما بستگی دارد. استفاده از این گزینه توصیه نمی‌شود؛ به‌جای آن از gpg-agent به‌همراه pinentry استفاده کنید.

(در نسخه‌های فعلی gnupg، برای استفاده از --ask-passphrase باید pinentry-mode loopback را در فایل .gnupg/gpg.conf خود تنظیم کنید. بدون این گزینه، gnupg از ابزار بسیار امن‌تر و توصیه‌شدهٔ pinentry استفاده می‌کند).

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

اگر اسکریپتی را برای پیش‌پردازش فایل‌های شاخصِ بارگیری‌شده تغییر داده‌اید یا یک Listfilter را ویرایش کرده‌اید، به احتمال زیاد می‌خواهید reprepro را با --noskipold اجرا کنید.

اگر یک فایل قفل وجود داشته باشد که نشان دهد نمونهٔ دیگری از reprepro در حال حاضر از پایگاه‌داده استفاده می‌کند، پس از ۱۰ ثانیه انتظار در هر بار، count بار تلاش مجدد انجام می‌دهد. مقدار پیش‌فرض 0 است و به این معنی است که بلافاصله با خطا خارج شود.
مقدار پیش‌فرض full است:
در دستورهای به‌روزرسانی (update)، برای هر فایلی که قرار است بارگیری شود بررسی می‌کند که روی کدام سیستم‌فایل قرار می‌گیرد و چقدر فضای خالی باقی مانده است.
برای غیرفعال کردن این رفتار، از none استفاده کنید.
هنگام بررسی فضای خالی، byte-count بایت را روی سیستم‌فایلِ حاوی دایرکتوری db/ ذخیره (رزرو) می‌کند. مقدار پیش‌فرض 104857600 (یعنی ۱۰۰ مگابایت) است که مقدار نسبتاً بزرگی است. اما از آنجا که هیچ راهی وجود ندارد از قبل بدانیم حجم پایگاه‌داده چقدر افزایش خواهد یافت و libdb از این لحاظ بسیار حساس است، تنها زمانی این مقدار را کاهش دهید که بدانید چه می‌کنید.
هنگام بررسی فضای خالی، byte-count بایت را روی سیستم‌فایل‌هایی که شامل دایرکتوری db/ نیستند ذخیره (رزرو) می‌کند. مقدار پیش‌فرض 1048576 (یعنی ۱ مگابایت) است.
متغیر محیطی GPG_TTY را تنظیم نمی‌کند، حتی زمانی که مقداردهی نشده باشد، stdin یک پایانه (ترمینال) باشد و /proc/self/fd/0 یک پیوند نمادین خواندنی باشد.
متغیر محیطی GNUPGHOME را به دایرکتوری داده‌شده به عنوان آرگومان این گزینه تنظیم می‌کند. و gpg شما به احتمال زیاد به‌جای «~/.gnupg»، از محتوای این متغیر استفاده خواهد کرد. برای اطمینان، نگاهی به gpg(1) بیندازید. این گزینه در خط فرمان معمولاً چندان کاربردی نیست، زیرا امکان تنظیم مستقیم متغیر محیطی وجود دارد. دلیل اصلی وجود آن این است که می‌توان از آن در conf/options استفاده کرد.
خروجی دستورهای list،‏ listmatched و listfilter را به اولین count نتیجه محدود می‌کند. مقدار پیش‌فرض 0 است که به معنای نامحدود است.
تعداد count نتیجهٔ اول را از خروجی list،‏ listmatched و listfilter نادیده می‌گیرد (حذف می‌کند).
قالب خروجی دستورهای list،‏ listmatched و listfilter را تنظیم می‌کند. این قالب شبیه به --showformat در dpkg-query است: فیلدها به‌صورت ${fieldname} یا ${fieldname;length}. مشخص می‌شوند. طول صفر یا عدم تعیین طول به معنای نامحدود است. اعداد مثبت به معنای پر کردن با فاصله از راست، و اعداد منفی پر کردن با فاصله از چپ است.

\n، \r، \t، \0 به ترتیب خط جدید (new-line)، بازگشت به ابتدای سطر (carriage-return)، نویسهٔ جهش (tabulator) و بایت صفر هستند. از بک‌اسلش (\) می‌توان برای گریزدهی (escape) هر نویسهٔ غیرحرفی یا غیررقمی استفاده کرد.

نام‌های فیلد ویژهٔ $identifier، $architecture، $component، $type، $codename نشان می‌دهند بسته در کجا پیدا شده است.

نام‌های فیلد ویژهٔ $source و $sourceversion نشان‌دهندهٔ سورس و نسخهٔ سورسی است که بسته به آن تعلق دارد. (یعنی ${$source} یا برابر با ${source} (بدون نسخهٔ احتمالی درون پرانتز در انتها) یا برابر با ${package} خواهد بود).

نام‌های فیلد ویژهٔ $basename، $filekey و $fullfilename اولین بخش فایل بسته‌ای که عضو این مدخل است (یعنی معمولاً فایل .deb،‏ .udeb یا .dsc) را به‌صورت basename، به‌صورت filekey (نام فایل به‌صورت نسبی نسبت به outdir) و نام کامل فایل همراه با پیشوند outdir نشان می‌دهند (یعنی به همان اندازه نسبی یا مطلق که outdir شما (یا basedir در صورت عدم تعیین outdir) است).

هنگامی که --list-format داده نشده باشد یا NONE باشد، پیش‌فرض معادل با
${$identifier} ${package} ${version}\n است.

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

اگر این گزینه را در خط فرمان وارد می‌کنید، فراموش نکنید که $ توسط پوستهٔ (shell) شما نیز تفسیر می‌شود. بنابراین باید آن را به‌درستی گریزدهی کنید؛ مثلاً با قرار دادن کل آرگومانِ --list-format در علامت‌های نقل‌قول تکی (single quotes)..TP --show-percent هنگام دانلود بسته‌ها، هر درصد تکمیل‌شده از بسته‌های دانلودشده را به همراه حجم بسته‌های به‌طور کامل دانلودشده نمایش می‌دهد. (تکرار این گزینه بسامد نمایش این خروجی را افزایش می‌دهد).

دستورهای pull و update از هر توزیعی که در آن یک هدف بیش از ۲۰٪ از بسته‌های خود (و دست‌کم ۱۰ بسته) را از دست بدهد، صرف‌نظر می‌کنند.

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

یک pull یا update را محدود می‌کند تا فقط روی بسته‌های متعلق به بستهٔ سورس src عمل کند. هیچ بستهٔ دیگری به‌روزرسانی نخواهد شد (مگر اینکه با یک --restrict-bin مطابقت داشته باشد). فقط بسته‌هایی که در غیر این صورت به‌روزرسانی می‌شدند یا دست‌کم با hold در یک FilterList یا FilerSrcList علامت‌گذاری شده‌اند، به‌روزرسانی خواهند شد.

این عمل را می‌توان با استفاده از علامت مساوی به یک نسخهٔ سورس محدود کرد، یا با استفاده از دونقطه به نوعی دیگر تغییر داد (FilterList را ببینید).

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

مانند --restrict عمل می‌کند، اما به بسته‌های باینری (.deb و .udeb) محدود می‌شود. بسته‌های سورس ارتقا داده نمی‌شوند مگر اینکه در یک --restrict آمده باشند.
مانند --restrict عمل می‌کند، اما یک فایل کامل را در قالب FilterSrcList می‌خواند.
مانند --restrict-bin عمل می‌کند، اما یک فایل کامل را در قالب FilterList می‌خواند.

اسکریپت hookscript مشخص‌شده را پس از خروج reprepro اجرا می‌کند. این اسکریپت متغیرهای محیطی معمول REPREPRO_* را به‌صورت تنظیم‌شده (یا نشده) دریافت می‌کند، و علاوه بر آن یک متغیر REPREPRO_EXIT_CODE که کد خروجی است که reprepro با آن خارج می‌شد (hook همیشه پس از پایان تجزیه اولیه گزینه‌های عمومی و نام دستور فراخوانی می‌شود، فارغ از اینکه reprepro کاری انجام داده باشد یا خیر). reprepro با کد خروج این اسکریپت به فرایند فراخواننده بازمی‌گردد. reprepro تمام پایگاه‌های داده خود را بسته و همه قفل‌هایش را آزاد کرده است، بنابراین می‌توانید reprepro را دوباره در این اسکریپت اجرا کنید (مگر اینکه، البته، پیش از این شخص دیگری در همان مخزن چنین کاری کرده باشد).

تنها برتری نسبت به اجرای همیشگی و مستقیم آن دستور پس از reprepro این است که می‌توانید برخی متغیرهای محیطی را تنظیم‌شده داشته باشید و اگر این گزینه در conf/options باشد، نمی‌توانید به این سادگی آن را فراموش کنید.

فرض بر این است که این اسکریپت نسبت به confdir قرار دارد، مگر اینکه نام آن با /، ./، +b/، +o/، یا +c/ آغاز شود، و نام نباید (به‌جز موارد ذکر شده در پیش) با یک + شروع شود.

یک نمونه اسکریپت به این صورت است:
#!/bin/sh


if [ "$REPREPRO_EXIT_CODE" -ne 0 ] ; then
exit "$REPREPRO_EXIT_CODE"
fi


echo "congratulations, reprepro with arguments: $*"
echo "seems to have run successfully. REPREPRO_ part of the environment is:"
set | grep ^REPREPRO_


exit 0

اسکریپت hookscript با یک فایل .outlog به عنوان آرگومان (واقع در logdir) که شامل شرح تمام تغییرات اعمال‌شده در outdir است، فراخوانی می‌شود.

فرض بر این است که این اسکریپت نسبت به confdir قرار دارد، مگر اینکه نام آن با /، ./، +b/، +o/، یا +c/ آغاز شود، و نام نباید (به‌جز موارد ذکر شده در پیش) با یک + شروع شود.

برای اطلاع از قالب فایل‌های .outlog ایجادشده برای این اسکریپت، به فایل manual.html ارائه‌شده همراه با reprepro مراجعه کنید.

تولید تمام فایل‌های شاخص برای توزیع‌های مشخص‌شده.

این دستور تمام فایل‌ها را بدون قید و شرط بازتولید می‌کند. تنها زمانی کاربرد دارد که بخواهید مطمئن شوید dists به‌روز است، پیش‌تر برخی عملیات دیگر را با --export=never فراخوانی کرده باشید، یا بخواهید یک دایرکتوری dists/codename اولیهٔ خالی اما کاملاً مجهز ایجاد کنید.

[ --delete ] createsymlinks [ codenames ]
پیوندهای نمادین suite را در دایرکتوری dists/ به گونه‌ای ایجاد می‌کند که به codename متناظر اشاره کنند.

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

فهرست کردن تمام بسته‌ها (سورس و باینری، مگر در صورت استفاده از -T یا -A ) با نام مشخص‌شده در تمامی مؤلفه‌ها (مگر در صورت استفاده از -C ) و معماری‌های (مگر در صورت استفاده از -A ) توزیع تعیین‌شده. اگر نام بسته‌ای مشخص نشود، همه‌چیز فهرست می‌شود. قالب خروجی را می‌توان با --list-format تغییر داد. برای دریافت تنها بخشی از نتیجه، از --list-max و --list-skip استفاده کنید.
مانند list عمل می‌کند، اما به جای یک بستهٔ منفرد، تمام بسته‌های منطبق با الگوی شبه‌پوستهٔ (glob) داده‌شده را فهرست می‌کند (یعنی *، ? و [chars] مجاز هستند).

مثال‌ها:

reprepro -b . listmatched test2 'linux-*' تمام بسته‌هایی که با linux- شروع می‌شوند را فهرست می‌کند.

مانند list عمل می‌کند، اما به جای یک بستهٔ منفرد، تمام بسته‌های منطبق با شرط ارائه‌شده را فهرست می‌کند.

قالب فرمول‌ها همانند خطوط وابستگی در فایل‌های control بسته‌های Debian به همراه امکاناتی اضافه است. این بدان معناست که یک فرمول از نام فیلدها همراه با یک شرط اختیاری برای محتوای آن در داخل پرانتز تشکیل می‌شود. این اجزا را می‌توان با علامت تعجب '!' (به معنای not)، نماد خط عمودی '|' (به معنای or) و ویرگول ',' (به معنای and) ترکیب کرد. علاوه بر این، می‌توان از پرانتزها برای تغییر اولویت پیوند استفاده کرد (در غیر این صورت اولویت '!' بیشتر از '|' و آن نیز بیشتر از ',' است).

مقادیر ارائه‌شده در عبارت جستجو مستقیماً به‌صورت الفبایی با سرآیندها در فایل شاخص مربوطه مقایسه می‌شوند. این بدان معنی است که هر بخش Fieldname (cmp value) از فرمول، دقیقاً برای بسته‌هایی صادق خواهد بود که در فایل Package یا Sources خود خطی دارند که با fieldname شروع می‌شود و مقدار آن به‌صورت الفبایی cmp نسبت به value است.

علاوه بر این از نگارش 3.11.0 به بعد reprepro، می‌توان از '%' به عنوان عملگر مقایسه استفاده کرد که نشان‌دهندهٔ تطبیق نام با الگوهای جانشین پوسته است (شامل '*'، '?' و '[..]').

نام‌های فیلد خاص که با '$' شروع می‌شوند، معانی خاصی دارند (از نگارش 3.11.1 در دسترس هستند):

$Version

نسخهٔ بسته؛ مقایسه به‌صورت الفبایی نیست، بلکه بر اساس رشته‌های نسخهٔ Debian انجام می‌شود.

$Source

نام سورس بسته.

$SourceVersion

نسخهٔ سورس بسته.

$Architecture

معماری بسته (در listfilter) یا معماری‌ای که بسته باید در آن قرار گیرد.

$Component

مؤلفه‌ای که بسته در آن قرار دارد (در listfilter) یا باید در آن قرار گیرد.

$Packagetype

نوع بسته (packagetype).

مثال‌ها:

reprepro -b . listfilter test2 'Section (== admin)' تمام بسته‌های موجود در توزیع test2 را که دارای فیلد Section با مقدار admin هستند، فهرست می‌کند.

reprepro -b . -T deb listfilter test2 'Source (== blub) | ( !Source , Package (== blub) )' تمام بسته‌های .deb را پیدا می‌کند که دارای فیلد Source برابر با blub باشند یا فیلد Source نداشته و فیلد Package آن‌ها blub باشد. (این یعنی تمام بسته‌های تولیدشده توسط بستهٔ سورس blub، به جز مواردی که همراه با سورس خود شمارهٔ نسخه نیز مشخص کرده‌اند).

reprepro -b . -T deb listfilter test2 '$Source (==blub)' روش بهتری برای انجام این کار است (اما فقط از نگارش 3.11.1 به بعد در دسترس است).

reprepro -b . listfilter test2 '$PackageType (==deb), $Source (==blub)' روش دیگری است (با کارایی کمتر).

reprepro -b . listfilter test2 'Package (% linux-*-2.6*)' تمام بسته‌هایی که نام آن‌ها با linux- شروع می‌شود و در ادامه شامل -2.6 هستند را فهرست می‌کند..TP ls package-name فهرست کردن نسخه‌های بستهٔ مشخص‌شده در تمام توزیع‌ها.

مشابه ls، اما با گروه‌بندی بر اساس مؤلفه (و چاپ نام مؤلفه‌ها).
حذف بسته‌ها در توزیع مشخص‌شده که نام بستهٔ آن‌ها به عنوان آرگومان ذکر شده است. نسخه‌های بسته باید با افزودن «=» و نسخه به نام آن (بدون فاصله) مشخص شوند. وقتی هیچ نسخه‌ای مشخص نشده باشد، آخرین نسخهٔ بسته حذف می‌شود.

توجه داشته باشید که همانند هر عملیات دیگری که بسته‌ای را حذف یا جایگزین می‌کند، ارجاع فایل‌های بستهٔ قدیمی برداشته می‌شود و بنابراین اگر این آخرین ارجاع به آن‌ها باشد و --keepunreferencedfiles مشخص نشده باشد، ممکن است به‌طور خودکار حذف شوند.

حذف تمام بسته‌هایی که listmatched با همان آرگومان‌ها فهرست می‌کرد.
حذف تمام بسته‌هایی که listfilter با همان آرگومان‌ها فهرست می‌کرد.
حذف تمام بسته‌های موجود در توزیع codename متعلق به بستهٔ سورس source-name. (در صورت مشخص شدن، محدود به مواردی با نسخهٔ سورس version).

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

مشابه removesrc، اما می‌تواند چندین نام سورس دریافت کند و نسخه‌های سورس باید با افزودن «=» و نسخه به نام (بدون فاصله) مشخص شوند.
همگام‌سازی توزیع‌های مشخص‌شده (اگر چیزی مشخص نشود، همه) طبق آنچه در پیکربندی با بالادست‌های آن‌ها تعیین شده است. توضیحات conf/updates را در زیر ببینید.
مشابه update، اما به جای اعمال تغییرات واقعی، آنچه را که تغییر خواهد داد نشان می‌دهد.
مشابه checkupdate، اما برای انسان‌ها کمتر مناسب و برای رایانه‌ها مناسب‌تر است.
این دستور تعیین می‌کند که یک update چه بسته‌هایی را حذف یا جایگزین خواهد کرد و آن بسته‌ها را حذف می‌کند. این امر می‌تواند برای کاهش فضای مورد نیاز هنگام ارتقا مفید باشد، اما برای مدتی بسته‌ها از فهرست‌ها محو می‌شوند؛ بنابراین کلاینت‌ها آن‌ها را به عنوان منسوخ علامت‌گذاری می‌کنند. علاوه بر این، اگر نتوانید بستهٔ به‌روزشده را در اجرای update بعدی (به‌امید خدا) دانلود کنید، به جای داشتن نسخهٔ قدیمی، در نهایت هیچ بسته‌ای نخواهید داشت. همچنین اگر از مثال pdiff یا موارد مشابه استفاده می‌کنید، این کار باعث حجیم شدن فایل‌های .diff خواهد شد. بنابراین هنگام استفاده از این گزینه محتاط باشید، یا بهتر است فضای بیشتری فراهم کنید تا update به درستی کار کند.
حذف تمام فایل‌های موجود در listdir (پیش‌فرض basedir/lists) که به هیچ قاعدهٔ به‌روزرسانی برای هیچ توزیعی تعلق ندارند. یعنی تمام فایل‌هایی در آن دایرکتوری حذف می‌شوند که هیچ دستور update در پیکربندی فعلی نمی‌تواند از آن‌ها استفاده کند. (فایل‌ها معمولاً در آنجا باقی می‌مانند تا در صورت نیاز مجدد، نیازی به دانلود دوبارهٔ آن‌ها نباشد؛ هرچند در بسیاری از موارد ساده حتی به این فایل‌ها هم نیازی نخواهد بود.)
کشیدن بسته‌های جدیدتر به درون توزیع‌های مشخص‌شده (اگر چیزی مشخص نشود، همه) از دیگر توزیع‌های موجود در همان مخزن. توضیحات conf/pulls را در زیر ببینید.
مشابه pull، اما به جای اعمال تغییرات واقعی، آنچه را که تغییر خواهد داد نشان می‌دهد.
مشابه checkpull، اما برای انسان‌ها کمتر مناسب و برای رایانه‌ها مناسب‌تر است.
گنجاندن بستهٔ باینری دبیان داده‌شده (.deb) در توزیع مشخص‌شده، با اعمال اطلاعات override و حدس زدن تمام مقادیری که داده نشده‌اند و قابل حدس زدن هستند.
مشابه includedeb، اما برای فایل‌های .udeb.
گنجاندن بستهٔ سورس دبیان داده‌شده (.dsc، شامل فایل‌های دیگر مانند .orig.tar.gz، .tar.gz و/یا .diff.gz) در توزیع مشخص‌شده، با اعمال اطلاعات override و حدس زدن تمام مقادیری که داده نشده‌اند و قابل حدس زدن هستند.

توجه داشته باشید که فایل‌های .dsc حاوی بخش (section) یا اولویت (priority) نیستند، اما فایل Sources.gz به آن‌ها نیاز دارد. دستور reprepro تلاش می‌کند فایل‌های .diff و .tar را برای یافتن آن‌ها تجزیه کند، اما فقط قادر به پردازش موارد ساده است. اگر reprepro نتواند آن‌ها را به‌طور خودکار استخراج کند، باید یک DscOverride مشخص کنید یا آن‌ها را از طریق -S و -P مشخص نمایید.

گنجاندن تمام بسته‌های یافت‌شده و مناسب در فایل .changes در توزیع مشخص‌شده، با اعمال اطلاعات override و حدس زدن تمام مقادیری که داده نشده‌اند و قابل حدس زدن هستند.
پویش یک دایرکتوری incoming و پردازش فایل‌های .changes یافت‌شده در آنجا. اگر نام فایلی ارائه شده باشد، پردازش به همان فایل محدود می‌شود. rulesetname مشخص می‌کند کدام مجموعه قوانین در conf/incoming تعیین می‌کند از کدام دایرکتوری incoming استفاده شود و بسته‌ها اجازهٔ ورود به کدام توزیع‌ها را داشته باشند. برای اطلاعات بیشتر بخش مربوط به این فایل را ببینید.
بررسی اینکه آیا تمام بسته‌ها در توزیع‌های مشخص‌شده همهٔ فایل‌های مورد نیاز را به‌طور صحیح ثبت کرده‌اند یا خیر.
بررسی اینکه آیا تمام فایل‌هایی که گمان می‌رود در pool هستند واقعاً هنوز در آنجا حضور دارند و دارای md5sum شناخته‌شده هستند یا خیر. هنگامی که fast مشخص شده باشد md5sum بررسی نمی‌شود.
محاسبهٔ تمام چکسام‌های پشتیبانی‌شده برای تمام فایل‌های موجود در pool. (نسخه‌های پیش از 3.3 فقط md5sum را ذخیره می‌کردند، 3.3 چکسام sha1 و 3.5 چکسام sha256 را اضافه کرد).
حذف فایل موروثی files.db پس از اطمینان از اینکه تمام اطلاعات در فایل جدید checksums.db نیز موجود است. (به عنوان روش جایگزین می‌توانید collecnewchecksums را فراخوانی کرده و فایل را خودتان حذف کنید.)
فراموش کردن اینکه چه فایل‌هایی مورد نیاز هستند و جمع‌آوری مجدد این اطلاعات.
چاپ اطلاعات مربوط به اینکه کدام فایل‌ها توسط چه کسی به عنوان مورد نیاز علامت‌گذاری شده‌اند.
چاپ فهرستی از تمام فایل‌هایی که تصور می‌شود در pool قرار دارند، اما نیازی به آن‌ها شناخته نشده است.
حذف تمام فایل‌های شناخته‌شده (و فراموش کردن آن‌ها) در pool که توسط هیچ چیزی به عنوان مورد نیاز علامت‌گذاری نشده‌اند.
حذف فایل‌های داده‌شده (و فراموش کردن آن‌ها) در pool در صورتی که برای استفاده توسط چیزی علامت‌گذاری نشده باشند. اگر هیچ آرگومان خط فرمانی داده نشود، stdin خوانده شده و هر خط به عنوان یک filekey در نظر گرفته می‌شود. این دستور بیشتر همراه با --keepunreferenced در conf/options یا در شرایطی مفید است که کاربر مایل نیست deleteunreferenced را اجرا کند؛ دستوری که تمام فایل‌های مجاز به حذف با این دستور را پاک می‌کند.
اعمال مجدد فایل‌های override روی توزیع‌های داده‌شده (یا تنها بخش‌هایی از آن‌ها که توسط -A، -C یا -T مشخص شده‌اند).

توجه: تنها اطلاعات کنترلی (control) تغییر می‌کنند. تغییر دادن یک section به مقداری که باعث حدس زدن یک مؤلفهٔ دیگر شود، هشداری ایجاد نخواهد کرد.

افزودن مجدد اطلاعات چکسام‌های فایل به نمایه‌های بسته.

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

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

چاپ تمام اطلاعات مربوط به بسته‌های سورس رهگیری‌شده در توزیع‌های داده‌شده..TP retrack [ codenames ] بازسازی پایگاه‌داده ردیابی (tracking database) برای توزیع‌های مشخص‌شده. این کار شامل سه مرحله است. ابتدا تمام فایل‌هایی که به عنوان بخشی از یک بسته منبع علامت‌گذاری شده‌اند، به عنوان استفاده‌نشده (unused) تنظیم می‌شوند. سپس تمام فایل‌هایی که در عمل استفاده می‌شوند، به همین صورت علامت‌گذاری می‌گردند. در نهایت tidytracks فراخوانی می‌شود تا همه مواردی را که طبق اطلاعات جدیدِ فایل‌های استفاده‌شده دیگر نیازی به آن‌ها نیست، حذف کند.

(این رفتار، هرچند کمی پیچیده و سنگین است، حتی فایل‌هایی را که صرفاً به دلیل حالت ردیابی keep نگه‌داری شده‌اند و فایل‌هایی را که استفاده دیگری ندارند اما به دلیل includechanges یا موارد وابسته به آن نگه‌داری شده‌اند، حفظ می‌کند. پیش از نسخه 3.0.0 چنین فایل‌هایی هنگام اجرای retrack از دست می‌رفتند).

تمام اطلاعات ردیابی بسته منبع را برای توزیع‌های داده‌شده حذف می‌کند.
داده‌های ردیابیِ نسخه داده‌شده از یک بسته منبع مشخص را از یک توزیع داده‌شده حذف می‌کند. این کار همچنین ارجاعات تمام فایل‌های استفاده‌شده را حذف می‌کند.
بررسی تمام اطلاعات ردیابی بسته منبع برای توزیع‌های مشخص‌شده، جهت یافتن فایل‌هایی که دیگر نباید نگه‌داری شوند.
رونوشت (کپی) بسته‌های داده‌شده از یک توزیع به توزیعی دیگر. بسته‌ها عیناً کپی می‌شوند و هیچ فایل override بررسی نمی‌شود. تنها مؤلفه‌ها و معماری‌های موجود در توزیع مبدأ کپی می‌شوند. نسخه‌های بسته باید با افزودن «=» و نسخه به نام (بدون فاصله) مشخص شوند. وقتی هیچ نسخه‌ای مشخص نشده باشد، آخرین نسخه بسته کپی می‌شود.
هر بسته را در توزیع مشخص‌شده با source-codename بررسی می‌کند (که در آن منظور از بسته، مانند همیشه، هر بسته‌ای اعم از dsc، deb یا udeb است) و بسته منبع مرتبط برای هر یک را شناسایی می‌کند. تمام بسته‌های منطبق با نام source-package مشخص‌شده (و هر version در صورت تعیین شدن) به توزیع destination-codename کپی می‌شوند. بسته‌ها عیناً کپی می‌شوند و هیچ فایل override بررسی نمی‌شود. تنها مؤلفه‌ها و معماری‌های موجود در توزیع مبدأ کپی می‌شوند.
کپی کردن بسته‌های منطبق با الگوی glob داده‌شده (به listmatched مراجعه کنید).

بسته‌ها عیناً کپی می‌شوند و هیچ فایل override بررسی نمی‌شود. تنها مؤلفه‌ها و معماری‌های موجود در توزیع مبدأ کپی می‌شوند.

کپی کردن بسته‌های منطبق با فرمول داده‌شده (به listfilter مراجعه کنید). (در صورتی که هیچ نسخه‌ای تعیین نشده باشد، تمام نسخه‌ها). بسته‌ها عیناً کپی می‌شوند و هیچ فایل override بررسی نمی‌شود. تنها مؤلفه‌ها و معماری‌های موجود در توزیع مبدأ کپی می‌شوند.
انتقال بسته‌های داده‌شده از یک توزیع به توزیعی دیگر. بسته‌ها عیناً منتقل می‌شوند و هیچ فایل override بررسی نمی‌شود. تنها مؤلفه‌ها و معماری‌های موجود در توزیع مبدأ منتقل می‌شوند. نسخه‌های بسته باید با افزودن «=» و نسخه به نام (بدون فاصله) مشخص شوند. در صورتی که هیچ نسخه‌ای تعیین نشود، آخرین نسخه بسته منتقل خواهد شد.
هر بسته را در توزیع مشخص‌شده توسط source-codename بررسی می‌کند (که در آن منظور از بسته، مانند همیشه، هر بسته‌ای اعم از dsc، deb یا udeb است) و بسته منبع مرتبط با هر یک را شناسایی می‌کند. تمام بسته‌هایی که با نام source-package مشخص‌شده (و هر version در صورت تعیین شدن) مطابقت دارند، به توزیع destination-codename منتقل می‌شوند. بسته‌ها عیناً منتقل می‌شوند و هیچ فایل override بررسی نمی‌شود. تنها مؤلفه‌ها و معماری‌های موجود در توزیع مبدأ منتقل می‌شوند.
انتقال بسته‌های منطبق با الگوی glob داده‌شده (به listmatched مراجعه کنید).

بسته‌ها عیناً منتقل می‌شوند و هیچ فایل override بررسی نمی‌شود. تنها مؤلفه‌ها و معماری‌های موجود در توزیع مبدأ منتقل می‌شوند.

انتقال بسته‌های منطبق با فرمول داده‌شده (به listfilter مراجعه کنید). (در صورتی که هیچ نسخه‌ای تعیین نشود، تمام نسخه‌ها). بسته‌ها عیناً منتقل می‌شوند و هیچ فایل override بررسی نمی‌شود. تنها مؤلفه‌ها و معماری‌های موجود در توزیع مبدأ منتقل می‌شوند.
مانند دستورهای copy عمل می‌کند، اما به جای کپی از یک توزیع دیگر، از یک تصویر لحظه‌ای (snapshot) تولیدشده با gensnapshot کپی انجام می‌دهد. توجه داشته باشید که این دستور کورکورانه به محتویات فایل‌های موجود در دایرکتوری dists/ شما اعتماد کرده و هیچ بررسی‌ای انجام نمی‌دهد.
حذف تمام پایگاه‌های داده بسته‌ها که دیگر در conf/distributions ظاهر نمی‌شوند. اگر گزینه --delete تعیین شده باشد، در صورت باقی ماندن بسته‌ها متوقف نخواهد شد. حتی بدون --delete نیز فایل‌هایی را که هنوز به عنوان مورد نیاز این هدف علامت‌گذاری شده‌اند، از حالت ارجاع خارج (unreference) می‌کند. (اگر آن مورد آخرین ارجاع بود، از --keepunreferenced استفاده کنید تا حذف نشوند.)

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

تولید یک تصویر لحظه‌ای (snapshot) از توزیع مشخص‌شده توسط codename در دایرکتوری dists/codename/snapshots/directoryname/ و ارجاع دادن به تمام فایل‌های مورد نیاز در pool بر اساس نیاز آن. هیچ فایل Contents تولید نمی‌شود و هیچ قلاب صادراتی (export hook) اجرا نخواهد شد.

توجه داشته باشید که در حال حاضر هیچ روش خودکاری برای حذف مجدد این تصویر لحظه‌ای وجود ندارد (حتی دستور clearvanished پس از ناپدید شدن خود توزیع نیز قفل فایل‌های ارجاع‌شده را باز نمی‌کند). شما باید خودتان دایرکتوری را حذف کرده و پیش از آنکه deleteunreferenced فایل‌های قفل‌شده توسط این تصویر را از pool حذف کند، به reprepro دستور دهید با اجرای unreferencesnapshot codename directoryname ارجاع را بردارد.

برای دسترسی به چنین تصویر لحظه‌ای با استفاده از apt، عبارتی مشابه زیر را به فایل sources.list خود اضافه کنید:
deb method://as/without/snapshot codename/snapshots/name main

حذف تمام ارجاعات تولیدشده توسط یک genshapshot با آرگومان‌های مشابه. این کار به فراخوانی بعدی deleteunferenced اجازه می‌دهد آن فایل‌ها را حذف کند. (شاخص‌های موجود در dists/ برای آن تصویر لحظه‌ای حذف نخواهند شد.)
اجرای تمام اسکریپت‌های خارجی مشخص‌شده در گزینه‌های Log: مربوط به توزیع‌های تعیین‌شده.
فهرست کردن بسته‌های منبع (منطبق بر glob) که احتمالاً نیاز به ساخت روی معماری داده‌شده دارند.

تمام بسته‌های منبع در توزیع داده‌شده را که فاقد بسته باینریِ ساخته‌شده از آن نسخه منبع برای معماری داده‌شده باشند، فاقد فایل .changes یا .log برای معماری داده‌شده باشند، فیلد Architecture آن‌ها شامل any یا os-any باشد (که در آن os بخش قبل از خط فاصله در معماری یا در صورت نبود خط فاصله linux است) یا شامل خود آن معماری باشد، و حداقل یک بسته در فیلد Binary آن‌ها هنوز در دسترس نباشد، فهرست می‌کند.

اگر به جای architecture عبارت any به کار رود، تمام معماری‌ها پیمایش شده و معماری به عنوان فیلد چهارم در هر خط چاپ می‌شود.

اگر architecture برابر با all باشد، تنها بسته‌های منبعی در نظر گرفته می‌شوند که فیلد Architecture آن‌ها شامل all باشد (یعنی مانند بالا با معماری‌های واقعی، اما در اینجا any کفایت نمی‌کند). توجه داشته باشید که نسخه dpkg-dev << 1.16.1 هر دوی any و all را هم‌زمان تنظیم نمی‌کند؛ بنابراین بسته‌های منبعی که هم بسته‌های وابسته به معماری و هم بسته‌های مستقل از معماری را می‌سازند، هرگز نمایش داده نخواهند شد مگر اینکه با dpkg-source به اندازه کافی جدیدی ساخته شده باشند).

تبدیل حافظه موقت (کش) فهرست فایل‌ها درون db/contents.cache.db به قالب جدید مورد استفاده از نسخه reprepro 3.0.0 به بعد.

اطمینان حاصل کنید که حداقل به اندازه نیمی از حجم فعلی فایل db/contents.cache.db فضای خالی در آن پارتیشن در دسترس باشد.

تبدیل ارجاعات درون db/references.db به قالب جدید مورد استفاده از نسخه reprepro 5.4.0 به بعد.

اطمینان حاصل کنید که حداقل به اندازه حجم فعلی فایل db/references.db فضای خالی در آن پارتیشن در دسترس باشد.

برای هر معماری از distribution (یا برای معماری مشخص‌شده)، بسته‌های با معماری all را از سایر معماری‌ها (اما از همان مؤلفه یا نوع بسته) تحت شرایط زیر اضافه می‌کند:


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

شما می‌توانید با استفاده از -A مشخص کنید که بسته‌های معماری all در کدام معماری‌ها جستجو شوند، و طبق معمول با -C/-T مؤلفه‌ها و انواع بسته‌های مشمول عملیات را محدود کنید.

عمدتاً دو کاربرد برای این دستور وجود دارد: اگر معماری جدیدی به یک توزیع اضافه کرده‌اید و می‌خواهید تمام بسته‌های با معماری all را درون آن کپی کنید. یا اگر برخی بسته‌های معماری all را تنها با استفاده از -A به برخی معماری‌ها اضافه کرده‌اید تا مانع از خرابی سایر معماری‌هایی شوید که بسته‌های باینری آن‌ها هنوز وجود نداشت، و اکنون می‌خواهید آن‌ها را به معماری‌هایی کپی کنید که احتمال بروز خرابی در آن‌ها کم است (چون باینری جدید در حال حاضر موجود است)..TP unusedsources [distributions] فهرست کردن تمام بسته‌های سورس که هیچ بسته باینری ساخته‌شده‌ای از آن‌ها یافت نشده است.

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

هر سطر شامل ۴ عدد است که هر کدام تعداد بایت‌ها را در مجموعه‌ای از بسته‌ها نشان می‌دهند، شامل: بسته‌های موجود در این توزیع (از جمله هر آنچه صرفاً به دلیل ردگیری نگه‌داری شده است)، بسته‌هایی که فقط در این توزیع هستند (هر چیزی که در این توزیع و یک تصویر لحظه‌ای (snapshot) از این توزیع باشد، فقط در این توزیع به شمار می‌آید)، بسته‌های موجود در این توزیع و تصویرهای لحظه‌ای آن، بسته‌هایی که فقط در این توزیع یا تصویرهای لحظه‌ای آن هستند.

اگر بیش از یک توزیع انتخاب شده باشد، مجموع آن‌ها را نیز فهرست می‌کند (که در آن «Only» به معنای حضور منحصراً در توزیع‌های انتخاب‌شده است، نه فقط در یکی از توزیع‌های انتخاب‌شده).

جستجوی بسته‌های باینری که فقط توضیحات کوتاه دارند و تلاش برای دریافت توضیحات بلند از فایل ‎.deb (و همچنین حذف Description-md5 احتمالی در این مورد).

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

_detect [ filekeys ]
جستجوی فایل‌هایی که filekey آن‌ها به عنوان آرگومان یا به صورت خطی از ورودی (در صورت اجرا بدون آرگومان) داده شده است، محاسبه md5sum آن‌ها و افزودنشان به فهرست فایل‌های شناخته‌شده. (هشدار: این یک عملیات سطح پایین است و هیچ اعتبارسنجی یا یکسان‌سازی ورودی انجام نمی‌شود.)
_forget [ filekeys ]
مانند _detect اما filekey داده‌شده را از فهرست فایل‌های شناخته‌شده حذف می‌کند. (هشدار: این یک عملیات سطح پایین است و هیچ اعتبارسنجی یا یکسان‌سازی ورودی انجام نمی‌شود.)
_listmd5sums
چاپ فهرستی از تمام فایل‌های شناخته‌شده و md5sumهای آن‌ها.
_listchecksums
چاپ فهرستی از تمام فایل‌های شناخته‌شده و چکسام‌های (checksums) ثبت‌شده آن‌ها.
_addmd5sums
نام مستعار برای دستور جدیدترِ
_addchecksums
افزودن اطلاعات فایل‌های شناخته‌شده (بدون انجام هیچ‌گونه بررسی) با قالب دقیق خروجی _listchecksums (به این معنی که حتی یک فاصله اضافی در هیچ کجای آن نباید وجود داشته باشد).
_dumpcontents identifier
چاپ تمام اطلاعات ذخیره‌شده از بخش مشخص‌شده مخزن. (یا به عبارت دیگر، محتوایی که فایل Packages یا Sources متناظر دریافت می‌کرد)

این دستور منسوخ شده است و در نسخه‌های آینده حذف خواهد شد.

_addreference filekey identifier
علامت‌گذاری دستی filekey به عنوان فایلی که توسط identifier مورد نیاز است.
_addreferences identifier [ filekeys ]
علامت‌گذاری دستی یک یا چند filekeys به عنوان فایل‌های مورد نیاز توسط identifier. اگر هیچ آرگومان خط فرمانی داده نشود، ورودی استاندارد (stdin) خوانده می‌شود و هر خط به عنوان یک filekey در نظر گرفته می‌شود.
_removereference identifier filekey
حذف دستی این علامت که فایل مذکور مورد نیاز این identifier است.
_removereferences identifier
حذف تمام ارجاعاتی که توسط identifier مورد نیاز است.
__extractcontrol .deb-filename
بررسی آنچه reprepro محتوای فایل control مربوط به فایل ‎.deb مشخص‌شده می‌داند.
__extractfilelist .deb-filename
بررسی آنچه reprepro فهرست فایل‌های مربوط به فایل ‎.deb مشخص‌شده می‌داند.
_fakeemptyfilelist filekey
درج یک فهرست فایل (filelist) خالی برای filekey. این یک ترفند خطرناک برای دور زدن فایل‌های ‎.deb خراب است که توسط reprepro قابل خواندن نیستند.
_addpackage codenam filename packages...
افزودن بسته‌ها از نام فایل مشخص‌شده به بخشی که با -C، -A و -T از توزیع مشخص‌شده معین گردیده است. در صورت استفاده نادرست، ممکن است اتفاقات بسیار عجیبی رخ دهد.
__dumpuncompressors
فهرست کردن قالب‌های فشرده‌سازی که قابل استخراج (uncompress) هستند و نحوه انجام آن.
__uncompress format compressed-file uncompressed-file
استفاده از ابزار استخراج داخلی یا خارجی برای فشرده‌گشایی فایل مشخص‌شده با قالب معین در مقصد تعیین‌شده.
_listcodenames
چاپ نام‌های رمزی (codenames) همه توزیع‌های پیکربندی‌شده، در هر سطر یکی.
_listconfidentifiers identifier [ distributions... ]
چاپ همه شناسه‌های پایگاه‌های داده فرعی مشتق‌شده از پیکربندی، در هر سطر یکی. اگر فهرستی از توزیع‌ها داده شود، تنها شناسه‌های مربوط به آن‌ها چاپ خواهند شد.
_listdbidentifiers identifier [ distributions... ]
چاپ همه شناسه‌های پایگاه‌های داده فرعی موجود در پایگاه داده فعلی، در هر سطر یکی. این باید زیرمجموعه‌ای از موارد چاپ‌شده توسط _listconfidentifiers باشد وگرنه بیشتر دستورها به جز clearvanished از اجرا خودداری می‌کنند؛ همچنین بسته به نسخه سازگاری پایگاه داده، در صورتی که reprepro پس از آخرین تغییر پیکربندی اجرا شده باشد، شامل تمامی آن‌ها خواهد بود..SH "فایل‌های پیکربندی (CONFIG FILES)" دستور reprepro از سه فایل پیکربندی استفاده می‌کند، که در دایرکتوری مشخص‌شده با --confdir یا در زیردایرکتوری conf/ از basedir جستجو می‌شوند.

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

برای اینکه گزینه‌های خط فرمان بتوانند گزینه‌های فایل options را لغو (override) کنند، بیشتر گزینه‌های بولی شکل متناظری دارند که با --no شروع می‌شود.

(تنها استثنا زمانی است که مسیر جستجوی فایل‌های پیکربندی تغییر کند؛ فایل options فقط یک بار و البته پیش از پردازش هر گزینه‌ای درون فایل options باز خواهد شد.)

فایل distributions همیشه مورد نیاز است و توزیع‌هایی را که باید مدیریت شوند شرح می‌دهد، در حالی که updates تنها هنگام همگام‌سازی با مخازن خارجی و pulls تنها هنگام همگام‌سازی با مخازن موجود در همان پایگاه‌داده reprepro مورد نیاز هستند.

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

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

یک بند می‌تواند تنها از یک فیلد تکی "!include:" تشکیل شود که باعث می‌شود فایل نام‌برده‌شده (نسبت به confdir مگر اینکه با ~/، +b/، +c/ یا / ) شروع شود) خوانده شود، گویی که در همین مکان قرار داشته است.

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

این فیلد اجباری، شناسه یکتای یک توزیع است و به عنوان نام دایرکتوری در dists/ استفاده می‌شود. این مقدار همچنین در فایل‌های Release کپی می‌شود.

توجه داشته باشید که این نام نباید تغییر کند. به احتمال زیاد شما به هیچ وجه نامی مانند testing یا stable در اینجا نمی‌خواهید (آن‌ها نام‌های suite هستند و قرار است بعداً به توزیع دیگری اشاره کنند).

این فیلد اختیاری صرفاً در فایل‌های Release کپی می‌شود. در دبیان این فیلد شامل نام‌هایی مانند stable، testing یا unstable است. برای ایجاد پیوندهای نمادین از Suite به Codename، از دستور createsymlinks در reprepro استفاده کنید.
اگر این فیلد وجود داشته باشد، آرگومان آن - جدا شده با یک اسلش - قبل از هر Component که در فایل اصلی Release نوشته می‌شود اضافه می‌گردد (مگر اینکه مولفه از قبل با آن شروع شده باشد)، و از انتهای فیلدهای Codename و Suite در آن فایل حذف می‌شود. همچنین اگر یک مولفه با آن شروع شود، دایرکتوری آن در دایرکتوری dists به این مقدار کوتاه می‌شود.
بنابراین


Codename: bla/updates
Suite: foo/updates
FakeComponentPrefix: updates
Components: main bad

یک فایل Release ایجاد می‌کند که شامل


Codename: bla
Suite: foo
Components: updates/main updates/bad

خواهد بود، اما در غیر این صورت چیزی تغییر نمی‌کند، در حالی که


Codename: bla/updates
Suite: foo/updates
FakeComponentPrefix: updates
Components: updates/main updates/bad

نیز یک فایل Release ایجاد می‌کند با


Codename: bla
Suite: foo
Components: updates/main updates/bad

اما بسته‌ها در واقع در مولفه‌های updates/main و updates/bad قرار خواهند گرفت، که به احتمال زیاد باعث می‌شود همان فایل فضای ذخیره‌سازی تکراری مصرف کند.

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

فهرستی از نام‌های توزیع‌ها. هنگامی که با دستور include مشخص شود که یک فایل .changes باید در این توزیع گنجانده شود و سربرگ توزیع آن فایل نه codename باشد، نه suite name، و نه هیچ نامی از این فهرست، یک خطای wrongdistribution ایجاد می‌شود. دستور processincoming نیز از این فیلد استفاده خواهد کرد؛ برای اطلاعات بیشتر توضیحات Allow و Default از فایل conf/incoming را ببینید.
این فیلد اختیاری صرفاً در فایل‌های Release کپی می‌شود.
این فیلد اختیاری صرفاً در فایل‌های Release کپی می‌شود.
این فیلد اختیاری صرفاً در فایل‌های Release کپی می‌شود.
این فیلد اختیاری صرفاً در فایل‌های Release کپی می‌شود. (مقدار آن به عنوان یک رشته اختیاری در نظر گرفته می‌شود، اگرچه هر چیزی به جز yes در حال حاضر مفهوم چندانی ندارد.)
این فیلد اختیاری صرفاً در فایل‌های Release کپی می‌شود. (مقدار آن به عنوان یک رشته اختیاری در نظر گرفته می‌شود، اگرچه هر چیزی به جز yes در حال حاضر مفهوم چندانی ندارد.)
این فیلد اختیاری صرفاً در فایل‌های Release کپی می‌شود.
این فیلد اختیاری صرفاً در فایل‌های Release کپی می‌شود. از این فیلد برای اعلام محل یافتن لاگ تغییرات بسته‌ها به دستور changelog در apt استفاده می‌شود. مثال:

Changelogs: https://apt.postgresql.org/pub/repos/apt/pool/@CHANGEPATH@.changelog
برای نحوه بسط @CHANGEPATH@ توسط apt، راهنمای apt.conf(5) را ببینید.
این فیلد اجباری معماری‌های باینری درون این توزیع را فهرست می‌کند و اینکه آیا شامل source است یا خیر (یعنی اگر موردی به نام source در این سطر وجود داشته باشد، این توزیع سورس دارد. تمام موارد دیگر مواردی را مشخص می‌کنند که پس از "binary-" قرار می‌گیرند تا نام‌های دایرکتوری را تشکیل دهند و در برابر فیلدهای "Architecture:" بررسی شوند.)

این فیلد در فایل‌های Release نیز کپی خواهد شد. (به استثنای مورد source که بدون توجه به حضور یا عدم حضور آن در اینجا، در بالاترین فایل Release ظاهر نخواهد شد)

این فیلد اجباری مولفه‌های یک توزیع را فهرست می‌کند. برای آگاهی از قواعد مربوط به اینکه بسته‌ها به‌طور پیش‌فرض در کدام مولفه گنجانده می‌شوند، بخش GUESSING را ببینید. این مقدار نیز در فایل‌های Release کپی خواهد شد.
فهرست مولفه‌های حاوی ddeb.ها.
مولفه‌های دارای زیرسلسله‌مراتب debian-installer حاوی udeb.ها. (برای مثال صرفاً "main").TP Update هنگامی که این فیلد وجود داشته باشد، مشخص می‌کند که کدام قواعد به‌روزرسانی برای این توزیع به کار می‌روند. همچنین می‌تواند یک قاعده جادویی خط تیره ("-") وجود داشته باشد؛ زیر را ببینید.
هنگامی که این فیلد وجود داشته باشد، مشخص می‌کند که کدام قواعد pull برای این توزیع به کار می‌روند. قواعد pull مانند قواعد Update هستند، اما داده‌های خود را از توزیع‌های دیگر دریافت می‌کنند و نه از منابع خارجی. توضیحات مربوط به conf/pulls را ببینید.
هنگامی که این فیلد وجود داشته باشد، یک فایل Release.gpg تولید خواهد شد. اگر مقدار آن "yes" یا "default" باشد، از کلید پیش‌فرض gpg استفاده می‌شود. اگر فیلد با یک علامت تعجب ("!") آغاز شود، اسکریپت مشخص‌شده برای انجام امضا اجرا می‌شود. در غیر این صورت، این مقدار به libgpgme داده می‌شود تا کلید مورد استفاده را تعیین کند.

اگر در امضا مشکلی وجود دارد، می‌توانید دستور زیر را امتحان کنید:
gpg --list-secret-keys value
تا ببینید gpg چگونه ممکن است این مقدار را تفسیر کند. اگر آن دستور هیچ کلیدی یا بیش از یک کلید را فهرست کرد، سعی کنید مقدار دیگری (مانند keyid) بیابید که gpg بتواند آسان‌تر آن را به یک کلید یکتا مرتبط کند.

اگر این کلید دارای عبارت عبور (passphrase) است، باید از gpg-agent یا گزینه ناامن --ask-passphrase استفاده کنید.

یک اسکریپت قلاب (hook) '!' در confdir جستجو می‌شود، مگر اینکه با موارد زیر آغاز شود: ~/، ./، +b/، +o/، +c/ یا / . این اسکریپت سه آرگومان خط فرمان دریافت می‌کند: نام فایل برای امضا، یک آرگومان خالی یا نام فایلی که با امضای درون‌متنی ایجاد می‌شود (یعنی InRelease)، و یک آرگومان خالی یا نام فایلی که برای ایجاد یک امضای مجزا به کار می‌رود (یعنی Release.gpg). اسکریپت در صورت تمایل می‌تواند هیچ فایل Release.gpg تولید نکند (در این صورت مخزن برای کلاینت‌های قدیمی‌تر بدون امضا به نظر می‌رسد)، اما تولید فایل‌های خالی مجاز نیست. دستور Reprepro منتظر پایان اسکریپت می‌ماند و در صورتی که اسکریپت به صورت عادی با وضعیت خروج ۰ پایان نیابد، فرایند برون‌ریزی (export) توزیعی را که این امضا بخشی از آن است لغو خواهد کرد. توصیه می‌شود پس از ! از یک فاصله استفاده شود تا از ناسازگاری‌ها با توسعه‌های احتمالی آینده جلوگیری گردد.

هنگامی که این فیلد وجود داشته باشد، فایل override مورد استفاده هنگام گنجاندن فایل‌های .deb را توصیف می‌کند.
هنگامی که این فیلد وجود داشته باشد، فایل override مورد استفاده هنگام گنجاندن فایل‌های .udeb را توصیف می‌کند.
هنگامی که این فیلد وجود داشته باشد، فایل override مورد استفاده هنگام گنجاندن فایل‌های .dsc را توصیف می‌کند.
نوع فایل‌های شاخص (Index) جهت برون‌ریزی را مشخص می‌کند. بخش اول مشخص می‌کند که فایل Index چه نامیده شود. آرگومان دوم نام فایل Release تولیدی را مشخص می‌کند، یا اگر حذف شود فایلی تولید نمی‌شود. سپس حداقل یکی از "."، ".gz"، ".xz" یا ".bz2" مشخص می‌کند که خروجی غیرفشرده، خروجی فشرده با gzip، خروجی فشرده با bzip2 یا هر ترکیبی از آن‌ها تولید شود. (پشتیبانی از bzip2 تنها در صورتی فعال است که برنامه با bzip2 کامپایل شده باشد، بنابراین اگر خودتان آن را کامپایل کرده باشید ممکن است در دسترس نباشد؛ همین مورد برای xz و liblzma نیز صادق است). اگر در ادامه آرگومانی بیاید که با نقطه شروع نمی‌شود، پس از تولید تمام فایل‌های شاخص اجرا خواهد شد. (برای مشاهده اینکه چه آرگومانی دریافت می‌کند مثال‌ها را ببینید). پیش‌فرض به صورت زیر است:
DebIndices: Packages Release . .gz
UDebIndices: Packages . .gz
DscIndices: Sources Release .gz
گزینه‌هایی برای تغییر نحوه برون‌ریزی و اینکه آیا اصلاً برون‌ریزی انجام شود یا خیر:
noexport هرگز این توزیع برون‌ریزی نشود. این بدان معناست که هیچ دایرکتوری در زیر dists/ ایجاد نخواهد شد و توزیع فقط برای رونویسی بسته‌ها به توزیع‌های دیگر مفید است.
keepunknown نادیده گرفتن فایل‌ها و دایرکتوری‌های ناشناخته در دایرکتوری برون‌ریزی‌شده. این در حال حاضر تنها گزینه موجود و حالت پیش‌فرض است، اما ممکن است در آینده تغییر کند، بنابراین از هم‌اکنون می‌توان آن را به صراحت درخواست کرد.
فعال‌سازی ایجاد فایل‌های Contents که تمام فایل‌های درون بسته‌های باینری یک توزیع را فهرست می‌کنند. (که فرآیندی بسیار زمان‌بر است، از قبل هشدار داده شد).

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

آرگومان‌های این فیلد فهرستی از گزینه‌ها هستند که با فاصله از هم جدا شده‌اند. اگر کلمه کلیدی udebs وجود داشته باشد، بسته‌های .udeb نیز فهرست می‌شوند (در فایلی به نام uContents-architecture). اگر کلمه کلیدی nodebs وجود داشته باشد، بسته‌های .deb فهرست نمی‌شوند. (فقط در کنار udebs کاربرد دارد). اگر حداقل یکی از کلمات کلیدی .، .gz، .xz و/یا .bz2 وجود داشته باشد، فایل‌های Contents به جای آنکه صرفاً فشرده با gzip باشند، به صورت غیرفشرده، فشرده با gzip و/یا bzip2 نوشته می‌شوند.

اگر گزینه percomponent وجود داشته باشد، به ازای هر مولفه (component) یک فایل Contents-arch ایجاد می‌شود. اگر گزینه allcomponents وجود داشته باشد، یک فایل سراسری Contents-arch تولید می‌شود. اگر هر دو داده شوند، هر دو ایجاد می‌شوند. اگر هیچ‌کدام مشخص نشده باشند، percomponent به عنوان پیش‌فرض در نظر گرفته می‌شود (نسخه‌های پیشین پیش‌فرض‌های دیگری داشتند).

سوئیچ‌های compatsymlink یا nocompatsymlink (تنها در صورتی ممکن است که allcomponents به صراحت مشخص نشده باشد) کنترل می‌کنند که آیا یک پیوند نمادین سازگاری ایجاد شود تا نسخه‌های قدیمی apt-file که به دنبال نام فایل‌های مستقل از مولفه هستند، دست‌کم محتویات مولفه اول را مشاهده کنند یا خیر.

مگر در صورتی که allcomponents مشخص شده باشد، در حال حاضر compatsymlinks گزینه پیش‌فرض است، اما این موضوع در آینده تغییر خواهد کرد (تخمین فعلی: پس از انتشار wheezy).

محدود کردن تولید فایل‌های Contents به معماری‌های داده‌شده. اگر این فیلد وجود نداشته باشد، تمام معماری‌ها پردازش می‌شوند. یک فیلد خالی به این معناست که هیچ معماری‌ای پردازش نمی‌شود، بنابراین چندان کاربردی نیست.
محدود کردن مولفه‌های پردازش‌شده برای فایل‌های Contents-arch به مولفه‌های داده‌شده. اگر این فیلد وجود نداشته باشد، تمام مولفه‌ها پردازش می‌شوند. یک فیلد خالی معادل مشخص کردن nodebs در فیلد Contents است، در حالی که یک فیلد غیرخالی nodebs موجود در آنجا را نادیده می‌گیرد و لغو می‌کند.
محدود کردن مولفه‌های پردازش‌شده برای فایل‌های uContents به مولفه‌های داده‌شده. اگر این فیلد وجود نداشته باشد و کلمه کلیدی udebs در فیلد Contents باشد، تمام فایل‌های .udeb مربوط به همه مولفه‌ها در فایل‌های uContents.arch قرار می‌گیرند. اگر این فیلد وجود نداشته باشد و کلمه کلیدی udebs در فیلد Contents نباشد، اصلاً هیچ فایل uContents-arch تولید نمی‌شود. یک فیلد غیرخالی مستلزم تولید فایل‌های uContents-arch است (دقیقاً مانند کلمه کلیدی udebs در فیلد Contents)، در حالی که فیلد خالی باعث می‌شود هیچ فایل uContents-arch تولید نشود.
مشخص‌کننده فایلی است (نسبت به confdir در صورتی که با ~/، +b/، +c/ یا / ) آغاز نشود) که تعیین می‌کند چه کسی مجاز به بارگذاری بسته‌ها است. بدون این فیلد هیچ محدودیتی وجود ندارد، و این فایل می‌تواند از طریق --ignore=uploaders نادیده گرفته شود. بخش UPLOADERS FILES در زیر را ببینید.
فعال‌سازی رهگیری (آزمایشی) بسته‌های سورس. فهرست آرگومان‌ها باید دقیقاً شامل یکی از موارد زیر باشد:
keep تمام فایل‌های یک بسته سورس داده‌شده را نگه می‌دارد، تا زمانی که به صراحت از طریق removetrack حذف شود. این گزینه در حال حاضر تنها راه برای نگه‌داشتن بسته‌های قدیمی‌تر در زمانی است که همه شاخص‌ها حاوی فایل‌های جدیدتر هستند.
all تمام فایل‌های متعلق به یک بسته سورس مشخص را تا زمانی که آخرین فایل آن دیگر در آن توزیع استفاده نشود نگه می‌دارد.
minimal فایل‌هایی را که دیگر در توزیعِ تحت رهگیری وجود ندارند حذف می‌کند. (فایل‌های changes، logs و includebyhand به محض اینکه هیچ فایلی در هیچ بخشی از توزیع نباشد حذف می‌شوند).
و هر تعداد از موارد زیر (یا هیچ‌کدام):
includechanges افزودن فایل .changes به فایل‌های رهگیری‌شده یک بسته سورس. بنابراین این فایل نیز درون مخزن pool قرار می‌گیرد.
includebyhand افزودن فایل‌های byhand و raw-* به فایل‌های رهگیری‌شده و در نتیجه قرار دادن آن‌ها در مخزن pool.
includebuildinfos افزودن فایل‌های buildinfo به فایل‌های رهگیری‌شده و در نتیجه در مخزن pool.
includelogs افزودن فایل‌های لاگ به فایل‌های رهگیری‌شده و در نتیجه در مخزن pool. (توجه داشته باشید که قرار دادن فایل‌های لاگ در فایل‌های changes یک ویژگی انحصاری reprepro است و در فایل‌های changes معمولی وجود ندارد).
embargoalls هنوز پیاده‌سازی نشده است.
keepsources حتی در صورت استفاده از حالت minimal، فایل‌های مبدا (source) را تا زمانی که هیچ فایلی دیگر مورد نیاز نباشد حذف نکن.
needsources هنوز پیاده‌سازی نشده است..TP Limit این مقدار را روی یک عدد صحیح بزرگ‌تر از یک تنظیم کنید تا چندین نسخه از یک بسته به ازای هر توزیع، معماری، مؤلفه و نوع نگهداری شود. با افزوده شدن نسخهٔ جدید بسته، تمام نسخه‌های قدیمی بسته که از این محدودیت فراتر روند حذف یا بایگانی خواهند شد (گزینهٔ Archive را ببینید). اگر این عدد صفر یا منفی باشد، تمام نسخه‌های بسته نگهداری خواهند شد. به‌طور پیش‌فرض تنها یک نسخه از بسته نگهداری می‌شود.
یک نام‌رمز (codename) مشخص می‌کند که باید پیش‌تر اعلان شده باشد (جهت جلوگیری از ایجاد حلقه). هنگامی که بسته‌ها از محدودیت تعداد نسخه (مشخص‌شده در Limit) فراتر روند، این بسته‌ها به جای حذف شدن، به توزیع مشخص‌شده منتقل خواهند شد.
فایلی را برای ثبت وقایع موارد افزوده‌شده و حذف‌شدهٔ این توزیع و/یا اسکریپت‌های خارجی برای فراخوانی هنگام افزودن یا حذف یک مورد مشخص می‌کند. باقی‌ماندهٔ خط Log: نام فایل است، و هر خط بعدی (طبق معمول، باید با یک فاصله آغاز شود) نام یک اسکریپت برای فراخوانی است. پیش از نام اسکریپت می‌توان گزینه‌هایی با قالب --type=(dsc|deb|udeb)، --architecture=name یا --component=name قرار داد تا اسکریپت تنها برای بخش‌های خاصی از توزیع فراخوانی شود. اسکریپتی با آرگومان --changes هنگامی فراخوانی می‌شود که یک فایل .changes توسط include یا processincoming پذیرفته شده باشد (و همراه با آرگومان‌های دیگر). برای هر دو نوع اسکریپت می‌توان --via=command را مشخص کرد که در این صورت اسکریپت تنها زمانی فراخوانی می‌شود که ناشی از دستور command در reprepro باشد.

برای اطلاعات دربارهٔ نحوهٔ فراخوانی و دیدن چند مثال، فایل manual.html در سورس‌کد reprepro یا دایرکتوری /usr/share/doc/reprepro/ را بررسی کنید.

اگر نام فایل گزارش با یک ممیز آغاز نشود، نسبت به دایرکتوری مشخص‌شده با --logdir در نظر گرفته می‌شود؛ اسکریپت‌ها نیز نسبت به --confdir سنجیده می‌شوند مگر اینکه با ~/، +b/، +c/ یا / آغاز شوند.

اگر این فیلد وجود داشته باشد، یک فیلد Valid-Until در فایل‌های Release تولیدشده برای این توزیع با تاریخی به همان میزان در آینده که آرگومان مشخص کرده است، قرار می‌گیرد.

این آرگومان باید عددی باشد که به دنبال آن یکی از یکاهای d، m یا y می‌آید، که در آن d به معنای روز، m به معنای ۳۱ روز و y به معنای ۳۶۵ روز است. بنابراین ValidFor: 1m 11 d باعث ایجاد سرایند Valid-Until: در فایل‌های Release می‌شود که به ۴۲ روز بعد در آینده اشاره دارد.

تمام تغییرات در این توزیع یا دایرکتوری آن در dists/codename را غیرمجاز می‌کند (به استثنای زیردایرکتوری‌های snapshot).
قلاب‌هایی را برای فراخوانی جهت مدیریت فایل‌های byhand/raw توسط processincoming (و شاید در نسخه‌های آینده توسط include) مشخص می‌کند.

هر خط از ۴ آرگومان تشکیل می‌شود: یک الگوی glob برای بخش (section) (به‌طور کلاسیک byhand، هرچند اوبونتو از raw-* استفاده می‌کند)، یک الگوی glob برای اولویت (priority) (معمولاً استفاده نمی‌شود)، و یک الگوی glob برای نام فایل.

آرگومان چهارم اسکریپتی است که در صورت تطابق تمام موارد فوق باید فراخوانی شود. این اسکریپت ۵ آرگومان دریافت می‌کند: نام‌رمز توزیع، بخش (معمولاً byhand)، اولویت (معمولاً تنها -)، نام فایل در فایل changes و نام کامل فایل (با processincoming در TempDir امن).

این فیلد اختیاری صرفاً در فایل‌های Release رونوشت می‌شود. از این فیلد استفاده می‌شود تا در آینده به apt اطلاع داده شود برای این Release به چه کلیدهایی اعتماد کند. (برای چگونگی تعیین اینکه reprepro امضا کند یا خیر و چگونه امضا کند، SignWith را ببینید).

نام این بالادست به‌روزرسانی (update-upstream) به‌گونه‌ای که بتوان در فیلد Update در conf/distributions از آن استفاده کرد.
یک URI مشابه آنچه می‌توان به apt داد، مانند http://ftp.debian.de/debian که صرفاً به متد متناظر apt-get داده می‌شود. (بنابراین یا باید apt-get نصب باشد، یا باید با --methoddir به مکانی اشاره کنید که چنین متدهایی در آن یافت شوند).
(هنوز آزمایشی:) یک URI پشتیبان، که در آن تمام فایل‌هایی که در اولی با شکست مواجه شدند امتحان می‌شوند. آن‌ها به همان متد URI قبلی داده می‌شوند (برای مثال هر دو //:http)، و کارساز پشتیبان باید همه‌چیز را در همان مکان داشته باشد. هیچ محاسبهٔ مجددی انجام نمی‌شود، بلکه پرونده‌های منفرد صرفاً مجدداً از این مکان امتحان می‌شوند.
می‌تواند شامل هر تعداد خط باشد، هر کدام با قالبی که apt-get --option انتظار دارد. (چندین خط ‐ طبق معمول ‐ با فاصله‌های ابتدایی مشخص می‌شوند).

برای مثال: Config: Acquire::Http::Proxy=http://proxy.yours.org:8080

نام قاعدهٔ به‌روزرسانی دیگری که این قاعده از آن مشتق می‌شود. قاعدهٔ حاوی From نباید شامل Method، Fallback یا Config. باشد. تمام فیلدهای دیگر از قاعدهٔ ارجاع‌شده در From استفاده می‌شوند، مگر اینکه در قاعدهٔ حاوی From یافت شوند. قاعدهٔ ارجاع‌شده در From می‌تواند خود شامل یک From باشد. برنامهٔ reprepro تنها زمانی فرض می‌کند دو فایل نمایهٔ دوردست یکسان هستند که هر دو اطلاعات Method خود را از یک قاعده دریافت کنند.
مجموعه‌ای (suite) که به‌روزرسانی از آن انجام می‌شود. اگر وجود نداشته باشد، نام‌رمز توزیعی که از این قاعده استفاده می‌کند به کار می‌رود. همچنین "*/whatever" با "<codename>/whatever" جایگزین می‌شود.
مؤلفه‌هایی که باید به‌روزرسانی شوند. هر مورد می‌تواند نام یک مؤلفه یا جفتی از مؤلفهٔ بالادست و مؤلفهٔ محلی باشد که با ">" جدا شده‌اند (مانند "main>all contrib>all non-free>notall").

اگر این فیلد وجود نداشته باشد، تمام مؤلفه‌های توزیعِ مبدأ برای به‌روزرسانی امتحان می‌شوند.

یک فیلد خالی به این معنی است که هیچ بستهٔ منبع یا deb. توسط این قاعده به‌روزرسانی نمی‌شود، بلکه تنها بسته‌های udeb. (در صورت وجود) به‌روزرسانی خواهند شد.

یک قاعده ممکن است مؤلفه‌هایی را فهرست کند که در تمام توزیع‌های استفاده‌کننده از این قاعده موجود نباشند. در این صورت مؤلفه‌های ناشناخته بدون هشدار نادیده گرفته می‌شوند. (مگر اینکه reprepro را با گزینهٔ --fast اجرا کنید؛ در این حالت دربارهٔ مؤلفه‌های غیرقابل استفاده در تمام توزیع‌های استفاده‌کننده از آن قاعده هشدار خواهد داد. به عنوان استثنا، دربارهٔ مؤلفه‌های غیرقابل استفاده به نام none هرگز هشداری داده نمی‌شود، به منظور سازگاری با نسخه‌های پیش از 3.0.0 که فیلد خالی در آن‌ها معنای متفاوتی داشت).

معماری‌هایی که باید به‌روزرسانی شوند. در صورت حذف، تمام معماری‌های توزیع مبدأ در نظر گرفته می‌شوند. (مانند مؤلفه‌ها، می‌توانید از ">" برای بارگیری از یک معماری و افزودن به معماری دیگر استفاده کنید. (این کار فقط تعیین می‌کند که بسته‌ها در کدام فهرست Package قرار گیرند؛ نه خط Architecture را در توضیحات بسته بازنویسی می‌کند و نه مقداری را که بر اساس آن در نام فایل تعیین شده است. به عبارت دیگر، بدون فیلترگذاری اضافی واقعاً کاربردی نیست)).
مشابه Components اما برای بسته‌های udeb.
فایل Release.gpg را بارگیری کرده و بررسی می‌کند که آیا این یک امضا از فایل Releasefile با کلید ارائه‌شده در اینجا است یا خیر. (در قالبی که "gpg --with-colons --list-key" چاپ می‌کند، یعنی ۱۶ رقم هگزادسیمال آخر اثر انگشت). چند کلید را می‌توان با جدا کردن آن‌ها به وسیلهٔ علامت «|» مشخص کرد. در این صورت، وجود امضایی از یکی از آن‌ها کافی خواهد بود. برای مجاز دانستن کلیدهای ابطال‌شده یا منقضی‌شده، یک «!» پس از کلید اضافه کنید. (اما برای پذیرش چنین امضاهایی، گزینهٔ مناسب --ignore نیز لازم است). برای مجاز دانستن زیرکلیدهای یک کلید مشخص، یک «+» پس از کلید اضافه کنید.
در صورت وجود این فیلد، هیچ فایل InRelease یا Release بارگیری نخواهد شد و بنابراین مقادیر md5sum سایر فایل‌های نمایه بررسی نخواهد شد.
در صورت وجود این فیلد، هیچ فایل InRelease بارگیری نمی‌شود و تنها برای Release (و Release.gpg ) تلاش خواهد شد.
اگر این فیلد در یک قاعدهٔ به‌روزرسانی باشد، مخزن مربوطه تخت (flat) فرض می‌شود، یعنی مخزنی بدون دایرکتوری dists و بدون زیردایرکتوری‌ها برای فایل‌های نمایه. (اگر خط متناظر در sources.list با یک ممیز پایان می‌یابد، ممکن است به این گزینه نیاز داشته باشید). آرگومان فیلد Flat: مؤلفه‌ای است که باید آن بسته‌ها در آن قرار داده شوند. هیچ‌یک از فیلدهای Components یا UDebComponents در یک قاعدهٔ به‌روزرسانی تخت مجاز نیستند. اگر فیلد Architecture شامل هرگونه موردی با علامت > باشد، بخش سمت چپ «>» نادیده گرفته می‌شود.
برای نمونه، خط sources.list زیر
deb http://cran.r-project.org/bin/linux/debian etch-cran/
ترجمه خواهد شد به
Name: R
Method: http://cran.r-project.org/bin/linux/debian
Suite: etch-cran
Flat: whatevercomponentyoudlikethepackagesin.TP IgnoreHashes این دستورالعمل به reprepro می‌گوید که درهم‌سازهای (هش‌های) فهرست‌شده در فایل Release بارگیری‌شده را (و تنها در فایل Release) بررسی نکند. مقادیر ممکن در حال حاضر md5، sha1 و sha256 هستند.

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

این می‌تواند فرمولی برای مشخص کردن این باشد که کدام بسته‌ها از این منبع پذیرفته شوند. قالب آن از تجزیه‌کننده‌ای که برای خطوط Dependency در نظر گرفته شده به نحوی دیگر استفاده می‌کند. برای دریافت تنها بسته‌های معماری all از “architecture (== all)” استفاده کنید، و برای دریافت بسته‌هایی با اولویت حداقل important از “priority (==required) | priority (==important)” استفاده نمایید.

برای مفهوم و معناشناسی فرمول‌ها، توضیحات دستور listfilter را ببینید.

FilterList، FilterSrcList
این دو گزینه هر کدام حداقل دو آرگومان می‌گیرند: اولین آرگومان، کنش جایگزین (پیش‌فرض) است. تمامی آرگومان‌های بعدی به‌عنوان نام فایل‌های فهرست در نظر گرفته می‌شوند.

در صورتی که نام فایل‌ها با ~/، +b/، +c/ یا /. شروع نشوند، نسبت به --confdir در نظر گرفته می‌شوند.

هر فایل فهرست شامل خطوطی است که از یک نام بسته تشکیل شده و به دنبال آن نویسه‌های فاصله (whitespace) و سپس یک کنش آمده است.

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

این قالب از دستور dpkg --get-selections پیش از multiarch الهام گرفته شده است و نام کنش‌ها احتمالاً تنها زمانی معنادار خواهند بود که فرض کنید این فایل خروجی این دستور از یک سیستم موجود است.

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

کلیدواژه‌های ممکن برای کنش‌ها عبارتند از:

بسته موجود را برای افزوده‌شدن به توزیع مقصد علامت‌گذاری می‌کند، مگر اینکه همان نسخه یا نسخه‌ای بالاتر پیش‌تر برای افزوده/نگه‌داشته‌شدن علامت‌گذاری شده باشد. (توجه داشته باشید که بدون قاعده حذف قبلی (-) یا کنش supersede، این مورد هرگز نسخه بسته را تنزیل (downgrade) نمی‌کند، زیرا نسخه موجود فعلی برای نگه‌داری علامت‌گذاری شده است).
مشابه install، اما بسته‌های جدید را به یک توزیع اضافه نمی‌کند.
مگر اینکه نسخه فعلی بسته بالاتر از نسخه بسته موجود باشد، بسته را برای حذف در توزیع مقصد علامت‌گذاری می‌کند. (برای حذف بسته‌ها در توزیع‌های الحاقی زمانی که به توزیع پایه رسیده‌اند، مفید است).
بسته تازه در دسترس قرار گرفته را نادیده می‌گیرد.
اگر یک بسته جدید یا نسخه جدیدتر در دسترس باشد، یک پیام هشدار در stderr چاپ می‌کند. در غیر این صورت بسته جدید را نادیده می‌گیرد (مانند deinstall یا purge).
بسته جدید نادیده گرفته می‌شود، اما هر تصمیم قبلی مبنی بر تنزیل یا حذف بسته در توزیع مقصد بازنشانی می‌گردد.
در صورت در دسترس بودن یک بسته جدید یا نسخه جدیدتر، کل فرایند ارتقا/دریافت (upgrade/pull) را لغو می‌کند.
= version
اگر بسته نامزد دارای نسخه داده‌شده باشد، مانند install رفتار می‌کند. در غیر این صورت، طوری ادامه می‌دهد که گویی این فایل فهرست نامی از این بسته نبرده است (یعنی در فایل‌های فهرست باقیمانده جستجو می‌کند یا از کنش جایگزین استفاده می‌نماید). در حال حاضر تنها یک ورودی از این دست به ازای هر بسته پشتیبانی می‌شود و نسخه در حال حاضر به عنوان رشته مقایسه می‌شود.
اگر هر دو گزینه FilterList و FilterSrcList وجود داشته باشند، اولی برای بسته‌های .deb و .udeb و دومی برای بسته‌های .dsc استفاده می‌شود.

اگر تنها FilterList وجود داشته باشد، به همه‌چیز اعمال می‌شود.

اگر تنها FilterSrcList وجود داشته باشد، آن نیز به همه‌چیز اعمال می‌شود، اما برای جستجو از نام بسته مبدأ (و نسخه مبدأ) استفاده می‌گردد.

این فیلد مشخص می‌کند که آیا بسته‌های مبدأ با مقدار تنظیم‌شده Extra-Source-Only، هنگام دریافت بسته‌های مبدأ نادیده گرفته شوند یا خیر. بدون این گزینه یا در صورتی که مقدار آن true باشد، آن بسته‌های مبدأ نادیده گرفته می‌شوند، در حالی که اگر روی no یا false تنظیم شود، در صورتی که فیلتر دیگری آن‌ها را مستثنی نکند، کاندید خواهند بود. (مقدار پیش‌فرض true احتمالاً پس از آنکه reprepro از چندین نسخه یک بسته پشتیبانی کند یا ابزارهای دیگری برای نگهداری بسته‌های مبدأ داشته باشد، تغییر خواهد کرد).
اگر این گزینه داده شود، برای تمام فایل‌های نمایه بارگیری‌شده اجرا می‌شود، به‌طوری که فهرست بارگیری‌شده به عنوان آرگومان اول و نام فایلی که به جای آن استفاده خواهد شد به عنوان آرگومان دوم داده می‌شود (مثلاً “ListHook: /bin/cp” کار می‌کند اما کاری انجام نمی‌دهد).

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

این شبیه به ListHook است، اما کل آرگومان به عنوان آرگومان به پوسته (shell) داده می‌شود، و فایل‌های ورودی و خروجی stdin و stdout هستند.

به‌عنوان مثال:
ListShellHook: cat
کار می‌کند اما کاری جز استفاده بیهوده از پوسته و cat انجام نمی‌دهد، در حالی که
ListShellHook: grep-dctrl -X -S apt -o -X -S dpkg || [ $? -eq 1 ]
قاعده به‌روزرسانی را به بسته‌های حاصل از بسته‌های مبدأ مشخص‌شده محدود خواهد کرد.

آرگومان‌های این فیلد مشخص می‌کنند که reprepro کدام فایل‌های نمایه را بارگیری خواهد کرد.

مقادیر مجاز عبارتند از .، .gz، .bz2، .lzma، .xz، .diff، force.gz، force.bz2، force.lzma، force.xz و force.diff.

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

مقدار پیش‌فرض .diff .xz .lzma .bz2 .gz . است؛ (یعنی اگر Packages.diff در فایل Release فهرست شده باشد آن را بارگیری کند، در غیر این صورت یا در صورت غیرقابل استفاده بودن، اگر .xz در فایل Release فهرست شده باشد و روشی برای استخراج آن وجود داشته باشد آن را بارگیری کند، سپس .lzma در صورت قابل استفاده بودن، سپس .bz2 در صورت قابل استفاده بودن، سپس .gz و در نهایت حالت فشرده‌نشده).

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

همراه با IgnoreRelease، برنامه reprepro اولین مورد در این فهرست را که بتوان از حالت فشرده خارج کرد بارگیری خواهد کرد (یعنی force همیشه فرض می‌شود) و مقدار پیش‌فرض .gz .bzip2 . .lzma .xz است..SS conf/pulls این فایل حاوی قواعد کشیدن (pulling) بسته‌ها از یک توزیع به توزیع دیگر است. اگرچه این کار را می‌توان با استفاده از قواعد به‌روزرسانی از طریق روش file یا copy و استفاده از نمایه‌های صادرشدهٔ آن توزیع دیگر نیز انجام داد، اما این روش سریع‌تر است. همچنین این روش تضمین می‌کند که از فایل‌های فعلی استفاده شود و هیچ کپی‌ای ایجاد نگردد. (این امر همچنین به این محدودیت منجر می‌شود که کشیدن بسته‌ها از یک کامپوننت به کامپوننتی دیگر امکان‌پذیر نیست.)

هر قاعده از فیلدهای زیر تشکیل شده است:

نام این قاعدهٔ pull به گونه‌ای که بتواند در فیلد Pull در conf/distributions استفاده شود.
نام رمزی (codename) توزیعی که بسته‌ها باید از آن کشیده شوند.
کامپوننت‌های توزیع مبدأ برای دریافت بسته‌ها.

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

یک قاعده ممکن است شامل کامپوننت‌هایی باشد که در تمام توزیع‌های استفاده‌کننده از این قاعده در دسترس نباشند. در این حالت کامپوننت‌های ناشناخته بدون هشدار نادیده گرفته می‌شوند. (مگر اینکه reprepro را با گزینهٔ --fast اجرا کنید، که در این صورت در مورد کامپوننت‌های غیرقابل استفاده در تمام توزیع‌هایی که از آن قاعده استفاده می‌کنند هشدار خواهد داد. به عنوان استثنا، در مورد کامپوننت‌های غیرقابل استفاده با نام none هرگز هشداری داده نمی‌شود؛ این امر جهت سازگاری با نسخه‌های پیش از 3.0.0 است که در آن‌ها فیلد خالی معنای متفاوتی داشت.)

معماری‌هایی که باید به‌روزرسانی شوند. در صورت حذف، تمام معماری‌های توزیع مبدأ در نظر گرفته می‌شوند. همانند conf/updates، می‌توانید از ">" برای دانلود از یک معماری و افزودن آن به معماری دیگر استفاده کنید. (و مجدداً، تنها در صورت فیلترسازی برای جلوگیری از مهاجرت بسته‌هایی با معماری غیر از all مفید خواهد بود).
مانند Components اما برای udebها.
مشابه قواعد به‌روزرسانی (update rules).

قالب فایل‌های override مورد استفاده توسط reprepro باید شبیه به قالب گسترش‌یافتهٔ ftp-archive باشد، به طور دقیق‌تر به صورت زیر است:

packagename field name new value

برای مثال:
kernel-image-2.4.31-yourorga Section protected/base
kernel-image-2.4.31-yourorga Priority standard
kernel-image-2.4.31-yourorga Maintainer That's me <me@localhost>
reprepro Priority required

تمام فیلدهای یک بستهٔ معین با مقدار جدید مشخص‌شده در فایل override جایگزین خواهند شد، به استثنای فیلدهای خاصی که با علامت دلار ($) آغاز می‌شوند. اگرچه نام فیلدها بدون توجه به بزرگی و کوچکی حروف (case-insensitive) مقایسه می‌شود، اما دقیقاً به همان شکلی که در فایل override آمده کپی می‌شود. (بنابراین پیشنهاد می‌کنم بزرگی و کوچکی حروف را دقیقاً مطابق با آنچه معمولاً در فایل‌های شاخص یافت می‌شود رعایت کنید، مبادا ابزارهای دیگر دچار سردرگمی شوند.) فراتر از کپی شدن، هدر Section است (مگر آنکه -S مشخص شده باشد)، که همچنین برای حدس زدن کامپوننت استفاده می‌شود (مگر آنکه -C وجود داشته باشد).

برخی مقادیر مانند Package، Filename، Size یا MD5sum ممنوع هستند، زیرا استفاده از آن‌ها باعث سردرگمی شدید reprepro می‌شود.

به عنوان یک قابلیت تکمیلی، reprepro از الگوها (patterns) نیز به جای packagenames پشتیبانی می‌کند. اگر نام بسته شامل '*'، '[' یا '?' باشد، یک الگو در نظر گرفته می‌شود و بر روی هر بسته‌ای اعمال می‌گردد که با هیچ override غیرالگویی و هیچ الگوی قبلی دیگری مطابقت نیافته باشد.

نام‌های فیلدی که با دلار ($) آغاز می‌شوند در داده‌های کنترلی صادرشده قرار نمی‌گیرند بلکه معنای خاصی دارند. موارد ناشناخته با اعلان هشدار نادیده گرفته می‌شوند. فیلدهای خاص عبارتند از:


$Component: دستورهای includedeb، includedsc، include و processincoming بسته را در کامپوننتی قرار می‌دهند که به عنوان مقدار مشخص شده است (مگر اینکه خود با -C جایگزین شود). توجه داشته باشید که روش صحیح تعیین کامپوننت، تنظیم فیلد section است و استفاده از این قابلیت الحاقی به احتمال زیاد کاربران و/یا ابزارها را به اشتباه خواهد انداخت.


$Delete: مقدار به عنوان نام فیلد در نظر گرفته شده و فیلدهایی با آن نام حذف می‌شوند. (به این ترتیب می‌توان فیلدهایی را که پیش‌تر اضافه شده‌اند بدون نیاز به حذف و افزودن دوبارهٔ بسته حذف کرد. همچنین فیلدهایی که از قبل در بسته گنجانده شده‌اند نیز قابل حذف هستند).

هر بخش (chunk) یک مجموعه قاعده برای دستور processincoming است. فیلدهای مجاز عبارتند از:

نام مجموعه قاعده، که به عنوان آرگومان برای دستور scan جهت مشخص کردن استفاده از این قاعده به کار می‌رود.
نام دایرکتوری برای پایش فایل‌های .changes است.
دایرکتوری‌ای که فایل‌های فهرست‌شده در فایل‌های .changes پردازش‌شده، پیش از خوانده شدن در آن کپی می‌شوند. می‌توانید با قرار دادن این دایرکتوری در همان نقطه اتصالی (mount point) که ساختار درختی pool (دست‌کم تا حدی) در آن قرار دارد، از برخی عملیات کپی جلوگیری کنید.
دایرکتوری‌ای که فایل‌های .changes، فایل‌های .log، فایل‌های .buildinfo و فایل‌های .byhand که در جای دیگری استفاده نشده‌اند، پس از پردازش در آن ذخیره می‌شوند.
هر آرگومان یا یک جفت name1>name2 است یا صرفاً name که شکل کوتاه‌شدهٔ name>name می‌باشد. هر name2 باید معرف یک توزیع باشد، چه از طریق Codename، یا یک Suite یکتا، یا یک AlsoAcceptFor یکتا از conf/distributions. در هر بارگذاری، هر مورد موجود در هدر Distribution: آن، به ترتیب از اول تا آخر با هر name1 در قواعد مقایسه می‌شود و بسته در اولین توزیعی که آن را بپذیرد قرار می‌گیرد. به عنوان مثال:
Allow: local unstable>sid
یا
Allow: stable>security-updates stable>proposed-updates
(توجه داشته باشید که این کار تنها زمانی منطقی است که Multiple روی true تنظیم شده باشد، یا اینکه افرادی وجود داشته باشند که فقط اجازهٔ بارگذاری در proposed-updates را دارند اما در security-updates نه).
هر بارگذاری که به دلیل هیچ‌یک از آرگومان‌های Allow در توزیع دیگری قرار نگرفته باشد، در صورتی که distribution آن را بپذیرد، در آن قرار داده می‌شود.
شکل قدیمی Options: multiple_distributions.
فهرستی از گزینه‌ها
multiple_distributions
امکان گنجاندن یک بارگذاری در چندین توزیع را فراهم می‌کند.

اگر یک فایل .changes چندین توزیع را فهرست کرده باشد، آنگاه reprepro با نخستین نام ارائه‌شده آغاز می‌کند، و تمام گزینه‌های Accept و Default را بررسی می‌کند تا توزیعی را بیابد که این بارگذاری بتواند در آن قرار گیرد.

اگر هیچ توزیعی پیدا نشود یا اگر این گزینه مشخص شده باشد، reprepro سپس همین روند را با نام دومین توزیع ارائه‌شده در فایل .changes تکرار می‌کند و به همین ترتیب ادامه می‌دهد.
limit_arch_all
اگر یک بارگذاری شامل باینری‌هایی از معماری خاصی به همراه بسته‌های با معماری all باشد، بسته‌های با معماری all تنها در معماری‌های حاضر در این بارگذاری قرار می‌گیرند. ترکیب آن با دستور flood سودمند است.

فهرستی از گزینه‌ها برای مجاز کردن مواردی که در غیر این صورت موجب خطا می‌شوند:
unused_files
اگر در فایل .changes فایل‌هایی فهرست شده باشند که متعلق به هیچ بسته‌ای در آن نباشند، فرآیند را با خطا متوقف نکن.
older_version
نادیده گرفتن بسته‌ای که افزوده نشده است به این دلیل که از پیش نسخه‌ای اکیداً جدیدتر از آن موجود است، به جای آنکه با این وضعیت به عنوان یک خطا برخورد شود.
unlisted_binaries
اگر یک فایل .changes حاوی فایل‌های .deb باشد که در هدر Binaries فهرست نشده‌اند، فرآیند را با خطا لغو نکن..TP Cleanup options فهرستی از گزینه‌ها برای مشخص کردن فایل‌های بیشتری در دایرکتوری incoming که باید حذف شوند:
unused_files
اگر مقدار unused_files در Permit موجود باشد، در این صورت آن فایل‌ها نیز هنگامی که بسته پس از پردازش موفق حذف می‌شود، پاک خواهند شد.
unused_buildinfo_files
اگر فایل‌های .buildinfo مربوط به فایل‌های .changes پردازش‌شده استفاده نشوند (نه توسط LogDir ذخیره شوند و نه همراه با Tracking: includebuildinfos باشند)، آن‌گاه آن‌ها را از دایرکتوری incoming حذف می‌کند. (این گزینه در صورتی که unused_files از پیش استفاده شده باشد، اثر مضاعفی ندارد.)
on_deny
اگر پردازش یک فایل .changes به دلیل نداشتن امضا یا مجاز نبودن توزیع‌های مشخص‌شده برای قرارگیری رد شود، آن فایل و تمام فایل‌های ارجاع داده‌شده توسط آن حذف می‌شوند.
on_error
اگر یک فایل .changes در حین پردازش خطایی ایجاد کند، آن فایل و فایل‌های ارجاع داده‌شده توسط آن حذف می‌شوند.

توجه داشته باشید که مجاز کردن پاک‌سازی (cleanup) در صف‌های ورودی در دسترس عموم، با فرستادن فایل‌های .changes امکان حمله منع سرویس (denial of service) را فراهم می‌سازد که می‌تواند فایل‌های دیگران را قبل از تکمیل شدن حذف کند؛ به‌ویژه هنگامی که فایل‌های .changes به‌طور مستقیم پردازش می‌شوند (برای مثال توسط inoticoming).

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

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

خطوط خالی و خطوطی که با علامت هش (#) شروع می‌شوند نادیده گرفته می‌شوند؛ تمامی خطوط دیگر باید از یکی از نه حالت زیر یا یک دستور include پیروی کنند:

که به هر کسی اجازه می‌دهد بسته‌های منطبق بر condition را بارگذاری کند،
که به تمام موارد منطبقی که فاقد سرآیند pgp/gpg هستند اجازه بارگذاری می‌دهد،
که به هر مورد منطبقی با هر امضای معتبری اجازه بارگذاری می‌دهد، یا
که به هر مورد منطبقی که توسط این key-id امضا شده باشد اجازه بارگذاری می‌دهد (باید بدون هیچ‌گونه فاصله‌ای مشخص شود). اگر key-id به یک + (به‌علاوه) ختم شود، امضا با یکی از زیرکلیدهای (subkey) این کلید اصلی نیز کفایت می‌کند.

مقدار key-id باید پسوندی از شناسه‌ای باشد که libgpgme برای تشخیص این کلید استفاده می‌کند؛ یعنی تعدادی رقم هگزادسیمال از انتهای اثرانگشت (fingerprint) کلید، اما نه بیشتر از آنچه libgpgme استفاده می‌کند. (حداکثر تعداد باید همان مقداری باشد که دستور gpg --list-key --with-colons چاپ می‌کند، که در زمان نگارش این متن حداکثر ۱۶ رقم هگزادسیمال است).

که به تمام اعضای گروه groupname اجازه می‌دهد. گروه‌ها می‌توانند با دستورات زیر ویرایش شوند:
برای افزودن یک key-id (برای جزئیات به بالا مراجعه کنید) به این گروه، یا
برای افزودن کل یک گروه به گروهی دیگر.

برای جلوگیری از دریافت هشدار در فایل‌های پیکربندی ناکامل، دستورهای زیر نیز وجود دارند:

برای اعلام اینکه یک گروه هیچ عضوی ندارد (از دریافت هشدارهای مبنی بر استفاده از آن بدون اعضا جلوگیری می‌کند) و
برای اعلام اینکه از یک گروه هنوز استفاده نشده است (از دریافت هشدار استفاده نشدن جلوگیری می‌کند).

خطی که با include شروع شود، باعث می‌شود باقی‌مانده آن خط به‌عنوان نام فایل تفسیر شود، که قبل از پردازش باقی‌مانده فایل فعلی، باز و پردازش خواهد شد.

تنها شرط‌هایی که در حال حاضر پشتیبانی می‌شوند عبارتند از:

*
که به معنای هر بسته‌ای است،
که به معنای هر بسته‌ای با نام سورس name است. ('*'، '?' و '[..]' مانند نویسه‌های عام در شل تفسیر می‌شوند).
با بارگذاری‌هایی مطابقت دارد که در آن‌ها هر بخش (section) با یکی از نام‌های مشخص‌شده تطابق داشته باشد. از آنجا که شرایط بارگذاری بسیار زود بررسی می‌شوند، این بخش همان چیزی است که در فایل .changes فهرست شده است، نه آن بخشی که در فایل override قرار دارد. (اما ممکن است این رفتار در آینده تغییر کند؛ اگر به هر یک از این دو رفتار نیاز دارید، اطلاع دهید).
همانند مورد قبلی است، اما نیازی نیست همه بخش‌ها از مجموعه داده‌شده باشند؛ بلکه کافی است حداقل یک بسته سورس یا باینری یکی از بخش‌های ارائه‌شده را داشته باشد.
با بارگذاری‌هایی مطابقت دارد که در آن‌ها هر باینری (از نوع deb یا udeb) با یکی از نام‌های مشخص‌شده همخوانی داشته باشد.
مجدداً، تنها وجود حداقل یک مورد به‌جای همه موارد نیاز است.
با بارگذاری‌هایی تطابق دارد که در آن‌ها هر بسته تنها شامل معماری‌هایی از مجموعه مشخص‌شده باشد. مقادیر source و all به‌عنوان معماری‌های یکتا در نظر گرفته می‌شوند. استفاده از نویسه‌های عام مجاز نیست.
مجدداً، تنها وجود حداقل یکی به‌جای همه موارد الزامی است.
با بارگذاری‌هایی مطابقت دارد که حداقل یک فایل byhand داشته باشند (یعنی فایلی با بخش byhand یا raw-something).
byhand 'section'(|'section')*
با بارگذاری‌هایی تطابق دارد که حداقل یک فایل byhand داشته باشند و تمام فایل‌های byhand نیز دارای بخشی باشند که در فهرست بخش‌های مشخص‌شده آمده باشد. (یعنی در حال حاضر byhand 'byhand'|'raw-*' همانند byhand است).
که به معنای هر بسته‌ای است به شرطی که قرار باشد در توزیع codename گنجانده شود. از آنجا که فایل uploaders بر پایه هر توزیع تعیین می‌شود، این مورد تنها برای استفاده مجدد از یک فایل پیچیده uploaders برای چندین توزیع کاربرد دارد.

قرار دادن کلمه not در ابتدای یک شرط، معنای آن را معکوس می‌کند. برای مثال:
allow not source 'r*' by anybody
بدین معناست که هر کسی می‌تواند بسته‌هایی را بارگذاری کند که نام سورس آن‌ها با حرف 'r' شروع نشود.

شرط‌های متعدد می‌توانند با and و or به یکدیگر متصل شوند، که در این میان or اولویت پیوند قوی‌تری دارد (اما هر دو ضعیف‌تر از not هستند). این بدان معناست که:
allow source 'r*' and source '*xxx' or source '*o' by anybody
معادل است با:
allow source 'r*xxx' by anybody
allow source 'r*o' by anybody

(سایر شرط‌ها به محض اینکه کاربران اعلام کنند چه محدودیت‌هایی برایشان کاربردی است اضافه خواهند شد. در حال حاضر تنها برای معماری‌ها مواردی برنامه‌ریزی شده است)..SH "نادیده‌گرفتن خطاها (ERROR IGNORING)" با قرار دادن --ignore در خط فرمان یا یک خط ignore در فایل تنظیمات (options)، انواع خطاهای زیر را می‌توان نادیده گرفت:

اگر در تجزیهٔ نسخهٔ نصب‌شدهٔ یک بسته خطایی وجود داشته باشد، به جای اعلام خطا، فرض می‌کند که آن نسخه از هر نسخهٔ دیگری قدیمی‌تر است، هیچ فایلی ندارد یا فاقد نام سورس است.
اگر یک فایل .changes یا .dsc شامل حداقل یک امضای نامعتبر و فاقد هرگونه امضای معتبر باشد (حتی نه منقضی‌شده و نه از یک کلید منقضی یا باطل‌شده)، reprepro فرض می‌کند که فایل خراب شده است و از به‌کارگیری آن خودداری می‌کند مگر اینکه این دستور ignore داده شده باشد.
اگر مقایسهٔ نسخهٔ قدیم و جدید ناموفق باشد، فرض می‌کند که نسخهٔ جدید تازه‌تر است.
اگر یک فایل .changes دارای نسخهٔ Source صریحی باشد که با نسخهٔ موجود در سرآیند فایل متفاوت است، reprepro آن را یک بارگذاری غیرنگهدارندهٔ باینری (NMU) فرض می‌کند. در این حالت، وجود فایل‌های سورس در فایل‌های .changes که توسط include یا processincoming پردازش می‌شوند مجاز نیست. افزودن --ignore=dscinbinnmu این مورد را برای دستور include مجاز می‌سازد.
اجازه می‌دهد رشته‌هایی که برای ساخت نام فایل‌ها استفاده می‌شوند خالی باشند (مانند نسخه‌ها، معماری‌ها، ...).
امکان می‌دهد که فایل‌های بدون پسوند .deb با includedeb، فایل‌های بدون پسوند .dsc با includedsc و فایل‌های بدون پسوند .changes با include وارد شوند.
بر سیاست دبیان (Debian policy) برای نام‌های بسته، سورس و نسخه‌ها پافشاری نمی‌کند. بنابراین تمام نویسه‌های ۷ بیتی به جز اسلش (چرا که ذخیره‌سازی فایل را مختل می‌کند) و نویسه‌های دارای نقش نحوی فعال (فاصله‌ها، زیرخط‌ها در نام فایل‌های درون فایل‌های .changes، پرانتزهای باز در نام سورس بسته‌های باینری) مجاز می‌شوند. برای مجاز کردن نویسه‌های ۸ بیتی علاوه بر این‌ها، از 8bit نیز استفاده کنید.
8bit (ناامن‌تر)
اجازه می‌دهد نویسه‌های ۸ بیتی که شبیه توالی‌های غیرمجاز و بیش‌ازحد طولانی UTF-8 نیستند، در نام فایل‌ها و مواردی که به عنوان بخشی از نام فایل استفاده می‌شوند به کار روند. با اینکه به احتمال زیاد توالی‌های بیش‌از‌حد طولانی UTF-8 رد می‌شوند، اما ممکن است نویسه‌های دیگری وجود داشته باشند که فایل‌سیستم شما آن‌ها را با نویسه‌های خاص اشتباه بگیرد و در نتیجه نام فایل‌هایی بسازد که احتمالاً معادل /mirror/pool/main/../../../etc/shadow باشند (که اگر reprepro را با دسترسی ریشه (root) اجرا نمی‌کنید باید امن باشد، مگر نه؟) یا به سادگی روی فایل conf/distributions شما بازنویسی کرده و دستوراتی به آن اضافه کند. بنابراین اگر بسیار محتاط هستید از این گزینه استفاده نکنید، مگر اینکه آن‌قدر محتاط باشید که کد کتابخانه‌ها، هسته و فایل‌سیستم‌های خود را بررسی کرده باشید.
انواع نامشخص ignore داده‌شده به --ignore را نادیده می‌گیرد.
هنگام به‌روزرسانی، در مورد توزیع تخت (flat) و غیرتخت از یک منبع یکسان و با نام مشابه هشداری نمی‌دهد. (به امید آنکه هرگز به آن نیازی نباشد.)
هنگام یافتن خطی که با فاصله آغاز نمی‌شود اما دونقطه (:) نیز ندارد، متوقف نمی‌شود. در غیر این صورت، از آنجا که این خطوط معنای مشخصی ندارند رد می‌شوند.
فیلدهای ناموجود در یک فایل .changes را که تنها بررسی می‌شوند اما پردازش نمی‌شوند، نادیده می‌گیرد. این موارد عبارتند از: Format، Date، Urgency، Maintainer، Description، Changes
هنگام گنجاندن یک فایل .dsc از یک فایل .changes، تلاش می‌کند فایل‌های مورد نیازی را که در فایل .changes فهرست نشده‌اند (مثلاً هنگامی که کسی فراموش کرده -sa را به dpkg-buildpackage بدهد) به جای اعلام خطا، از دایرکتوری‌ای که فایل .changes در آن قرار دارد دریافت کند. (هرچند --delete با این فایل‌ها کار نخواهد کرد.)
خطوطی را که فقط شامل فاصله (حداقل یک فاصله) هستند مجاز می‌شمارد. از آنجا که این خطوط تکه‌ها (chunks) را جدا نمی‌کنند و در نتیجه رفتار غیرمنتظره‌ای در reprepro ایجاد خواهند کرد، به طور پیش‌فرض پیام‌های خطا تولید می‌کنند.
فایل .changes حاوی فایل‌هایی برای معماری‌ای که در سرآیند Architecture درون آن فهرست نشده را رد نمی‌کند.
فایل .changes حاوی فایل‌های .deb با بسته‌هایی که نام آن‌ها در سرآیند "Binary:" آن فایل changes فهرست نشده را رد نمی‌کند.
هنگامی که فایل packages.db شامل پایگاه‌داده‌هایی برای ترکیب‌های codename/packagetype/component/architectures باشد که در فایل distributions شما فهرست نشده‌اند، متوقف نمی‌شود.

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

هنگامی که فایل tracking شامل پایگاه‌داده‌هایی برای توزیع‌هایی باشد که در فایل distributions شما فهرست نشده‌اند، متوقف نمی‌شود.

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

فیلدهای ناشناخته را در فایل‌های پیکربندی نادیده می‌گیرد، به جای آنکه از اجرا خودداری کند.
دیگر فایلی از نوع .changes را که برای هیچ‌یک از معماری‌های فهرست‌شده در سرآیند Architecture درون آن فایلی ندارد، رد نمی‌کند.
از گزینه‌های خط فرمانی که در عملیات مشخص‌شده استفاده نمی‌شوند (مانند --architecture) ایراد نمی‌گیرد.
دستور include بسته‌هایی را خواهد پذیرفت که در غیر این صورت توسط فایل uploaders رد می‌شدند.
دربارهٔ خطوط "Architecture:" نادرست در فایل‌های Packages بارگیری‌شده هشدار نمی‌دهد. (توجه داشته باشید که معماری‌های نادرست هنگام دریافت موارد از مخازن تخت یا وارد کردن موارد از یک معماری به معماری دیگر، همیشه نادیده گرفته می‌شوند).
اگر قرار باشد یک فایل .changes در توزیعی قرار گیرد که در فیلد "Distribution:" آن فایل فهرست نشده است، خطایی صادر نمی‌کند.
فایل .changes حاوی فایل‌های .deb با نظری متفاوت در مورد نسخهٔ بستهٔ سورس را رد نمی‌کند.
(توجه: reprepro در اینجا تنها مقایسهٔ تحت‌اللفظی می‌کند، نه مفهومی.)
فایل .changes حاوی فایل‌های .dsc با نسخه‌ای متفاوت را رد نمی‌کند.
(توجه: reprepro در اینجا تنها مقایسهٔ تحت‌اللفظی می‌کند، نه مفهومی.)
امضاهای دارای کلیدهای منقضی‌شده را می‌پذیرد. (تنها در صورتی که کلید منقضی‌شده صریحاً درخواست شده باشد).
امضاهای منقضی‌شده با کلیدهای منقضی‌شده را می‌پذیرد. (تنها در صورتی که کلید صریحاً درخواست شده باشد).
امضاهای دارای کلیدهای باطل‌شده را می‌پذیرد. (تنها در صورتی که کلید باطل‌شده صریحاً درخواست شده باشد)..SH "حدس زدن (GUESSING)" هنگام گنجاندن یک بسته باینری یا مبدا بدون تعریف صریح مؤلفه با -C نخستین مؤلفه‌ای در نظر گرفته می‌شود که نام بخش (section) را داشته باشد، پیشوندِ بخش باشد، پسوندِ بخش باشد، یا بخش را به عنوان پیشوند داشته باشد، یا هر مؤلفه دیگری. (به همین ترتیب)

بنابراین مشخص کردن مؤلفه‌های: "main non-free contrib non-US/main non-US/non-free non-US/contrib" باید برای نمونه، "non-US" را به "non-US/main" و "contrib/editors" را به "contrib" نگاشت کند، در حالی که داشتنِ فقط "main non-free and contrib" به عنوان مؤلفه‌ها باید "non-US/contrib" را به "contrib" و "non-US" را به "main" نگاشت نماید.

نکته: اگر می‌خواهید بسته‌ها در main قرار گیرند، همیشه main را به عنوان نخستین مؤلفه تعیین کنید.

نکته: برخلاف dak، در اینجا non-US و non-us دو چیز متفاوت هستند...

Codename شناسه اصلی یک توزیع معین. معمولاً مواردی مانند sarge، etch یا sid هستند.

نام یک فایل بدون هرگونه اطلاعات دایرکتوری.
فایل‌های changes می‌توانند شامل فایل‌هایی با بخش 'byhand' (در Debian) یا 'raw-' (در Ubuntu) باشند. این فایل‌ها بسته نیستند، بلکه داده‌های دیگری هستند که تولید شده (معمولاً همراه با بسته‌ها) و سپس همراه با این فایل‌های changes بارگذاری می‌شوند.

در reprepro می‌توان این فایل‌ها را در pool در کنار بسته‌هایشان با قابلیت ردگیری (tracking) ذخیره کرد، در صورت استفاده از processincoming در دایرکتوری لاگ قرار داد، یا به یک اسکریپت قلاب (hook) تحویل داد (در حال حاضر فقط با processincoming امکان‌پذیر است).

موقعیت نسبی نسبت به outdir (همان‌طور که در فیلد "Filename:" در Packages.gz یافت می‌شود).
موقعیت نسبی نسبت به /
اصطلاحاتی مانند sparc، i386، mips، ... . برای اشاره به بسته‌های سورس (source packages)، گاهی با source نیز مانند یک معماری برخورد می‌شود.
مواردی مانند main، non-free و contrib (طبق سیاست‌ها و در برخی برنامه‌های دیگر section نیز نامیده می‌شود؛ reprepro در اینجا از شیوه نام‌گذاری apt پیروی می‌کند).
مواردی مانند base، interpreters، oldlibs و non-free/math (طبق سیاست‌ها و در برخی برنامه‌های دیگر subsections یا زیربخش نیز نامیده می‌شوند).
چک‌سام یک فایل در قالب "<md5sum of file> <length of file>"

دستور reprepro هرگز بسته‌ای را با نسخه‌ای که از پیش دارد به‌روزرسانی نخواهد کرد. این کار معادل با بازسازی کل پایگاه‌داده با هر ارتقای منفرد خواهد بود. برای اعمال اجباری همان نسخه جدید، ابتدا آن را حذف و سپس به‌روزرسانی کنید. (اگر فایل‌های بسته بدون تغییر نام تغییر کرده‌اند، مطمئن شوید که فایل دیگر توسط reprepro به خاطر سپرده نشده باشد. بدون گزینه --keepunreferencedfiled و در صورت عدم بروز خطا حین حذف، باید از پیش فراموش شده باشد؛ در غیر این صورت دستور deleteunreferenced یا حتی دستوراتی مانند __forget ممکن است کارساز باشند.)

یک علامت خط تیره (-) به عنوان یک کلمه تنها در خط Update: یک توزیع، همه چیز را برای حذف نشانه‌گذاری می‌کند. این نشان موجب می‌شود قواعد بعدی بسته‌ها را حتی در صورت داشتن نسخه‌های (قطعاً) پایین‌تر دریافت کنند. اگر یک قاعده بعدی بسته را در حالت نگه‌داشت (hold) قرار دهد (در صورتی که برایتان سوال است، hold هنوز پیاده‌سازی نشده است) یا بسته‌ای با همان نسخه دریافت کند (که دریافت نخواهد کرد، بالا را ببینید)، این نشان برداشته می‌شود. اگر نشان در پایان پردازش همچنان وجود داشته باشد، بسته حذف خواهد شد.

بنابراین خط "Update: - rules " باعث می‌شود تمام بسته‌ها دقیقاً به بالاترین نسخه‌ای که در rules یافت می‌شود تبدیل شوند. خط "Update: near - rules " همان کار را انجام می‌دهد، با این تفاوت که اگر نیاز به دانلود بسته‌ها داشته باشد، ممکن است آن را از near دانلود کند، مگر اینکه بیش از حد دچار سردرگمی شود. (برای نمونه زمانی سردرگم می‌شود که near یا rules چندین نسخه از بسته را داشته باشند و بالاترین نسخه در near نخستین نسخه در rules نباشد، زیرا هرگز بیش از یک منبع احتمالی را برای یک بسته به خاطر نمی‌سپارد.)

هشدار: این قاعده به تمام سه‌گانه‌های نوع/مؤلفه/معماریِ (type/component/architecture) یک توزیع اعمال می‌شود، نه فقط آن‌هایی که یک قاعده به‌روزرسانی دیگر به آن‌ها اعمال شده است. (این بدان معناست که همه چیز را در آن‌ها حذف خواهد کرد!)

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

در صورت عدم ارائه گزینه‌های -b یا --basedir، دایرکتوری مشخص‌شده در این متغیر به‌جای دایرکتوری جاری استفاده می‌شود.
این متغیر همچنین در تمام اسکریپت‌های قلاب (hook) فراخوانی‌شده توسط reprepro مقداردهی می‌شود (به‌صورت نسبی نسبت به دایرکتوری جاری یا مطلق، بسته به اینکه reprepro چگونه آن را دریافت کرده است).
در صورتی که گزینه --confdir ارائه نشود، دایرکتوری موجود در این متغیر استفاده می‌شود.
این متغیر همچنین در تمام اسکریپت‌های قلاب فراخوانی‌شده توسط reprepro مقداردهی می‌شود (به‌صورت نسبی نسبت به دایرکتوری جاری یا مطلق، بسته به اینکه reprepro چگونه آن را دریافت کرده است).
به‌طور مستقیم استفاده نمی‌شود، بلکه صرفاً در اسکریپت‌های قلاب فراخوانی‌شده توسط reprepro روی دایرکتوری‌ای تنظیم می‌شود که زیردایرکتوری pool در آن قرار دارد (به‌صورت نسبی نسبت به دایرکتوری جاری یا مطلق، بسته به اینکه reprepro چگونه آن را دریافت کرده است).
به‌طور مستقیم استفاده نمی‌شود، بلکه صرفاً در اسکریپت‌های قلاب فراخوانی‌شده توسط reprepro روی دایرکتوری dists تنظیم می‌شود (به‌صورت نسبی نسبت به دایرکتوری جاری یا مطلق، بسته به اینکه reprepro چگونه آن را دریافت کرده است).
به‌طور مستقیم استفاده نمی‌شود، بلکه صرفاً در اسکریپت‌های قلاب فراخوانی‌شده توسط reprepro روی مقداری تنظیم می‌شود که با --logdir قابل تنظیم است.
این دو متغیر محیطی در اسکریپت‌های Log: و ByHandHooks: تنظیم (یا حذف) می‌شوند و نشان می‌دهند چه دستور و چه فایلی موجب فراخوانی قلاب شده است (در صورت وجود).
این متغیر محیطی در اسکریپت‌های Log: تنظیم (یا حذف) می‌شود و نشان می‌دهد کدام قاعده به‌روزرسانی یا pull موجب این تغییر شده است.
این متغیر محیطی در اسکریپت‌های Log: تنظیم (یا حذف) می‌شود و مشخص می‌کند که یک بسته از چه توزیع دیگری کپی شده است (با دستورهای pull و copy).
در اسکریپت‌های FilterList: و FilterSrcList: تنظیم می‌شوند.
مستقیماً توسط reprepro استفاده نمی‌شود. اما reprepro از libgpgme استفاده می‌کند که خود gpg را برای امضا و تأیید امضاها فراخوانی می‌نماید. و gpg شما به احتمال زیاد به‌جای "~/.gnupg" از محتوای این متغیر استفاده خواهد کرد. برای اطمینان، نگاهی به gpg(1) بیندازید. همچنین می‌توانید با گزینه --gnupghome به reprepro اعلام کنید که این متغیر را مقداردهی کند.
هنگامی که gpg-agent در حال اجرا باشد و هنوز عبارت عبور (passphrase) را ذخیره نکرده باشد، gpg به احتمال زیاد تلاش می‌کند یک برنامه pinentry را برای دریافت آن اجرا کند. اگر آن برنامه pinentry-curses باشد، بدون این متغیر احتمالاً شکست خواهد خورد، زیرا نمی‌تواند ترمینالی برای پرسش پیدا کند. در این موارد می‌توانید این متغیر را روی مقداری مانند خروجی $(tty) یا $SSH_TTY یا هر مقدار دیگری که بیانگر یک ترمینال قابل استفاده است تنظیم کنید. (همچنین ممکن است بخواهید اطمینان حاصل کنید که واقعاً یک ترمینال در دسترس دارید. در ssh ممکن است به گزینه -t نیاز داشته باشید تا حتی هنگام درخواست از gpg برای اجرای یک دستور مشخص، یک ترمینال اختصاص یابد).

به‌طور پیش‌فرض، اگر stdin یک ترمینال باشد، reprepro این متغیر را روی مقصدی که پیوند نمادین /proc/self/fd/0 به آن اشاره دارد تنظیم می‌کند، مگر اینکه با --noguessgpgtty مشخص کرده باشید که این کار را انجام ندهد..SH "اشکالات (BUGS)" افزایش پرگویی (verbosity) همواره چیزهایی را نشان می‌دهد که فرد مایل به دانستن آن‌ها نیست. (اگرچه شاید این امر اجتناب‌ناپذیر و از نتایج قانون مورفی باشد)

برنامهٔ reprepro از berkeley db استفاده می‌کند، که اشتباه بزرگی بود. آزاردهنده‌ترین مشکلی که هنوز راهکاری برای آن پیدا نشده، خراب شدن پایگاه‌داده هنگام پر شدن فضای دیسک است. (خوشبختانه اگر این اتفاق حین به‌روزرسانی و هنگام بارگیری بسته‌ها رخ دهد، تنها پایگاه‌دادهٔ فایل‌ها تحت تأثیر قرار می‌گیرد، که بازسازی آن آسان (هرچند زمان‌بر) است؛ فایل recovery را در مستندات ببینید). در حالت ایده‌آل پایگاه‌داده را روی پارتیشن دیگری قرار دهید تا از این مشکل جلوگیری شود.

در حالی که بخش منبع عمدتاً به عنوان معماری source در نظر گرفته می‌شود، ممکن است برخی از بخش‌ها هنوز از این شیوه‌نگارش استفاده نکنند.

در نگارش woody این وضعیت معمولاً بدین معنا بود که دایرکتوری .gnupg در $HOME وجود ندارد، اما برنامه خودش آن را ایجاد می‌کرد و در صورت فراخوانی دوباره با همان دستور، reprepro با موفقیت اجرا می‌شد. از نگارش sarge به بعد، این مشکل گاهی دوباره پدیدار می‌شود، اما دیگر نه قابل بازتولید است و نه خودبه‌خود برطرف می‌شود. تلاش کنید دستور gpg --verify file-you-had-problems-with را به‌صورت دستی با کاربری که reprepro تحت آن اجرا می‌شود و با همان $HOME اجرا کنید. این کار به تنهایی ممکن است مشکل را رفع کند. این دستور نباید هیچ پیامی چاپ کند، مگر شاید
gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
در صورتی که فایل امضا نشده باشد.
عدم درج .orig.tar.gz زمانی که نگارش یک فایل .changes به -0 یا -1 ختم نمی‌شود
اگر dpkg-buildpackage بدون گزینهٔ -sa برای ساخت نگارشی اجرا شود که بازنگری دبیانی آن -0 یا -1 نیست، فایل .orig.tar.gz را در فایل .changes فهرست نمی‌کند. اگر بخواهید چنین فایلی را با استفاده از دستور include در reprepro بگنجانید در حالی که فایل .orig.tar.gz از پیش در pool وجود ندارد، reprepro خطایی گزارش خواهد کرد. این مشکل را می‌توان با روش‌های زیر دور زد:
فراخوانی dpkg-buildpackage با -sa (توصیه‌شده)
کپی کردن فایل .orig.tar.gz در مکان مناسب در pool از قبل
فراخوانی reprepro با --ignore=missingfile (توصیه نمی‌شود)
فایل‌های باقی‌مانده در دایرکتوری pool.
برنامهٔ reprepro گاهی اوقات در حذف فایل‌ها کمی بیش از حد محتاط است. هنگامی که مشکلی پیش می‌آید و خطاهایی رخ می‌دهد، گاهی همه چیز را همان‌جایی که هست رها می‌کند. برای مشاهدهٔ اینکه reprepro چه فایل‌هایی را در دایرکتوری pool شما به خاطر دارد ولی در حال حاضر نیازی به آن‌ها نمی‌بیند، می‌توانید از این دستور استفاده کنید:
reprepro dumpunreferenced
برای حذف آن‌ها:
reprepro deleteunreferenced

قطع کردن اجرای reprepro مشکلات خود را دارد. برخی از کارها (مانند گفتگو با متدهای apt، عملیات مربوط به پایگاه‌داده) در صورت قطع شدن در زمان نامناسب می‌توانند مشکل‌ساز شوند. از سوی دیگر، مشکلات طراحی در کد برنامه باعث می‌شود تشخیص اینکه وضعیت فعلی برای قطع شدن خطرناک است یا بی‌خطر، دشوار باشد. بنابراین اگر reprepro سیگنالی دریافت کند که معمولاً برای درخواست توقف آرام به یک فرایند ارسال می‌شود، به عملیات خود ادامه می‌دهد، اما هیچ عملیات جدیدی را آغاز نمی‌کند. (یعنی به apt-methods فایل جدیدی را برای بارگیری اعلام نخواهد کرد، بسته‌ای را در مقصد جایگزین نمی‌کند مگر آنکه از پیش شروع به انجام آن کرده باشد، فایل‌هایی را که ارجاع‌زدایی شده‌اند حذف نخواهد کرد، و غیره).

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

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

باگ‌ها یا درخواست‌های امکانات جدید (wishlist) را به BTS دبیان گزارش دهید
(برای مثال با استفاده از reportbug reprepro در دبیان)
یا مستقیماً به

حق نشر © 2004,2005,2006,2007,2008,2009,2010,2011,2012
این یک نرم‌افزار آزاد است؛ شرایط رونوشت‌برداری را در سورس‌کد ببینید. هیچ‌گونه ضمانتی وجود ندارد؛ حتی برای قابلیت فروش یا تناسب با یک هدف خاص.

2013-05-04 reprepro