نتایج رای گیری در سیستم های init دبیان خلاصه شده است

منتشر شده یافته ها رای گیری عمومی (GR، وضوح کلی) توسعه دهندگان پروژه دبیان درگیر در نگهداری بسته و تعمیر و نگهداری زیرساخت، در مورد پشتیبانی از سیستم های چندگانه init انجام شده است. مورد دوم ("B") در لیست برنده شد - systemd ترجیح داده می شود، اما امکان حفظ سیستم های اولیه سازی جایگزین باقی می ماند. رای گیری با استفاده از روش انجام شد کندورسه، که در آن هر رای دهنده همه گزینه ها را به ترتیب ترجیح خود رتبه بندی می کند و هنگام محاسبه نتیجه در نظر گرفته می شود که چه تعداد از رای دهندگان یک گزینه را به گزینه دیگر ترجیح می دهند.

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

بسته‌ها می‌توانند شامل فایل‌های واحد systemd و اسکریپت‌های init برای شروع خدمات باشند. بسته‌ها ممکن است از هر ویژگی سیستمی مورد نظر نگهدارنده بسته استفاده کنند، تا زمانی که ویژگی‌ها با قوانین دبیان مطابقت داشته باشند و به ویژگی‌های آزمایشی یا پشتیبانی نشده دبیان در بسته‌های دیگر مرتبط نباشند. علاوه بر systemd، بسته‌ها ممکن است شامل پشتیبانی از سیستم‌های init جایگزین نیز باشند و اجزایی را برای جایگزینی رابط‌های خاص systemd ارائه دهند. تصمیمات مربوط به گنجاندن وصله ها توسط نگهبانان به عنوان بخشی از رویه های استاندارد گرفته می شود. دبیان متعهد به کار با توزیع‌های مشتق شده است که استفاده از سیستم‌های init دیگر را انتخاب می‌کنند، اما تعامل در سطح نگهدارنده ایجاد می‌شود، که تصمیم می‌گیرد که کدام ویژگی‌های تهیه‌شده توسط توزیع‌های شخص ثالث در ترکیب اصلی دبیان پذیرفته شوند و کدام یک باقی بماند. در توزیع مشتق

به یاد بیاوریم که در سال 2014 کمیته فنی تایید شده انتقال توزیع پیش فرض در systemd، اما نه کار کرد تصمیمات مربوط به حمایت از سیستم های تامین چندگانه (موردی که نشان دهنده عدم تمایل کمیته به تصمیم گیری در مورد این موضوع است رای را برنده شد). رهبر کمیته توصیه کرد که نگهبانان بسته حمایت خود را از sysvinit به عنوان یک سیستم ابتدایی جایگزین حفظ کنند، اما اشاره کرد که او نمی تواند دیدگاه خود را تحمیل کند و در هر مورد باید تصمیم به طور مستقل اتخاذ شود.

پس از این، برخی از توسعه دهندگان تلاش کردند تلاش برای انجام رای عمومی، اما رای گیری اولیه نشان داد که نیازی به تصمیم گیری در مورد استفاده از سیستم های چندگانه اولیه وجود ندارد. چند ماه پیش، پس از چالش ها و مسائل با گنجاندن بسته elogind (الزامی برای اجرای GNOME بدون systemd) در شاخه آزمایشی به دلیل درگیری با libsystemd، این موضوع دوباره توسط رهبر پروژه Debian مطرح شد، زیرا توسعه دهندگان نتوانستند توافق کنند و ارتباط آنها به یک مشکل تبدیل شد. رویارویی و به بن بست رسید.

گزینه های در نظر گرفته شده:

تمرکز اصلی روی systemd است. ارائه پشتیبانی برای سیستم‌های init جایگزین یک اولویت نیست، اما نگهدارنده‌ها ممکن است به صورت اختیاری اسکریپت‌های init را برای چنین سیستم‌هایی در بسته‌ها قرار دهند.

systemd ترجیح داده می شود، اما امکان حفظ سیستم های اولیه سازی جایگزین باقی مانده است. فن آوری هایی مانند elogind که به برنامه های متصل به systemd اجازه می دهد تا در محیط های جایگزین اجرا شوند، مهم تلقی می شوند. بسته ها ممکن است شامل فایل های init برای سیستم های جایگزین باشد.

پشتیبانی از انواع سیستم های init و امکان بوت کردن دبیان با سیستم های init به غیر از systemd.
برای اجرای سرویس‌ها، بسته‌ها باید شامل اسکریپت‌های init باشند؛ ارائه تنها فایل‌های واحد سیستمی بدون اسکریپت‌های init sysv غیرقابل قبول است.

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

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

اجباری کردن پشتیبانی از سیستم های اولیه سازی چندگانه. ارائه توانایی اجرای دبیان با سیستم‌های init غیر از systemd همچنان برای پروژه مهم است. هر بسته باید با گرداننده‌های pid1 غیر از systemd کار کند، مگر اینکه نرم‌افزار موجود در بسته در ابتدا فقط با systemd کار کند و از اجرای بدون systemd پشتیبانی نمی‌کند (عدم وجود اسکریپت‌های init تنها برای کار با systemd به حساب نمی‌آید) .

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

ادامه بحث مورد را می توان برای کاهش رتبه گزینه های غیرقابل قبول استفاده کرد.

منبع: opennet.ru