سم هارتمن، رهبر پروژه دبیان، برای درک اختلافات مربوط به تحویل بسته elogind به عنوان بخشی از توزیع. در ماه جولای، تیم مسئول آماده سازی نسخه ها بود گنجاندن elogind در شاخه تست، زیرا این بسته با libsystemd در تضاد است.
به یاد بیاورید رابط های مورد نیاز برای اجرای گنوم را بدون نصب systemd فراهم می کند. این پروژه به عنوان یک فورک از systemd-login ایجاد شد، در یک بسته جداگانه قرار گرفت و از اتصال به اجزای systemd آزاد شد. از جمله موارد دیگر، elogind نسخه خود را از کتابخانه libelogind ارائه می دهد که تعدادی از عملکردهای ارائه شده در libsystemd را بر عهده می گیرد و در حین نصب جایگزین این کتابخانه می شود.
دلایل مسدود کردن تداخل با بسته systemd و خطر جایگزینی libsystemd با یک libelogind جایگزین بود که کاملاً با کتابخانه منبع در سطح ABI ناسازگار است.
برچسب‌های بسته elogind را با کتابخانه‌های systemd متضاد می‌دانند، اما ذاتاً طوری طراحی شده است که فقط بدون systemd کار کند، و تضاد با systemd در واقع مفید است زیرا از نصب اشتباه elogind جلوگیری می‌کند. از طرف دیگر، در شکل فعلی، تلاش از طریق APT برای به روز رسانی پیکربندی از systemd به نسخه با sysvinit و elogind منجر به با APT کار نمی کند. اما حتی اگر این نقص برطرف شود، انتقال از systemd به elogind بدون حذف محیط‌های کاربر از قبل نصب شده غیرممکن است.
توسعه دهندگان elogind بودند elogind را برای کار بر روی سیستم استاندارد libpam بدون استفاده از لایه libpam-elogind خود تطبیق دهید. انتقال elogind به libpam-systemd به دلیل عدم پشتیبانی از مفهوم slices با مشکل مواجه می شود، اما توسعه دهندگان elogind نمی خواهند به انطباق کامل با API دست یابند و دقیقاً تمام قابلیت های systemd را تکرار کنند، زیرا elogind فقط حداقل را ارائه می دهد. عملکردی برای سازماندهی ورود کاربران است و هدف آن تکرار همه زیرسیستم های سیستم نیست.
حل مشکلات فنی شرح داده شده باید در سطح تعامل بین تیم انتشار و حفظ کننده های elogind و systemd حل شود، اما رهبر پروژه مجبور به مداخله شد زیرا تیم ها نتوانستند به توافق برسند، کار مشترک به رویارویی تبدیل شد و راه حل برای حل مشکل مشکل به بن بست رسید، که در آن هر طرف به روش خود حق داشت. به گفته سام هارتمن، وضعیت در حال نزدیک شدن به ایالتی است که نیاز به رای عمومی (GR، قطعنامه عمومی) دارد، که در آن جامعه در مورد سیستم های جایگزین برای init و حمایت از sysvinit با elogind تصمیم می گیرد.
اگر اعضای پروژه به تنوع سیستم‌های init رأی دهند، همه نگهدارنده‌ها برای حل این مشکل با یکدیگر همکاری خواهند کرد یا توسعه‌دهنده‌های خاصی برای کار بر روی این موضوع منصوب می‌شوند و نگهدارنده‌ها دیگر نمی‌توانند سیستم جایگزین init را نادیده بگیرند، سکوت کنند، یا روند را به تاخیر بیندازد.
در حال حاضر در مخزن در حال حاضر بسته های 1033 که واحدهای خدماتی را برای systemd ارائه می دهند، اما شامل اسکریپت های init.d نمی شوند. برای حل این مسئله فایل‌های سرویس را به‌طور پیش‌فرض عرضه کنید، اما کنترل‌کننده‌ای آماده کنید که به‌طور خودکار دستورات این فایل‌ها را تجزیه کند و اسکریپت‌های init.d را بر اساس آن‌ها تولید کند.
اگر جامعه تصمیم بگیرد که دبیان به اندازه کافی از یک سیستم init پشتیبانی می کند، دیگر نمی توانیم نگران sysvinit و elogind باشیم و فقط روی فایل های واحد و systemd تمرکز کنیم. این تصمیم بر پورت هایی که از هسته لینوکس استفاده نمی کنند تأثیر منفی می گذارد (, и ) اما هنوز چنین پورت هایی در آرشیو اصلی وجود ندارد و وضعیت را ندارند .
اتصال به systemd همچنین تغییر جهت توزیع را در آینده دشوارتر می‌کند و آزمایش‌های بیشتر در زمینه مقداردهی اولیه و مدیریت خدمات را محدود می‌کند. حفظ elogind در فرم کار بسیار ساده تر از حذف آن و سپس تلاش برای اضافه کردن مجدد آن است. هر گزینه تصمیم گیری دارای مزایا و معایب است، بنابراین قبل از رای دادن به بحث کامل در مورد همه جوانب مثبت و منفی نیاز است.
منبع: opennet.ru