سام هارتمان، قائد مشروع دبيان، لفهم الخلافات المرتبطة بتسليم حزمة elogind كجزء من التوزيع. في يوليو، الفريق المسؤول عن إعداد الإصدارات إدراج elogind في فرع الاختبار، نظرًا لأن هذه الحزمة تتعارض مع libsystemd.
يذكر أن يوفر الواجهات اللازمة لتشغيل جنوم دون تثبيت systemd. تم إنشاء المشروع على شكل شوكة من systemd-logind، وتم وضعه في حزمة منفصلة وتم تحريره من الارتباط بمكونات systemd. من بين أشياء أخرى، توفر elogind نسختها الخاصة من مكتبة libelogind، والتي تتولى عددًا من الوظائف المقدمة في libsystemd وتحل محل هذه المكتبة أثناء التثبيت.
كانت أسباب الحظر هي وجود تعارض مع حزمة systemd وخطر استبدال libsystemd بـ libelogind بديل، وهو غير متوافق تمامًا مع المكتبة المصدر على مستوى ABI.
تُصنف الحزمة elogind على أنها متعارضة مع مكتبات systemd، ولكنها مصممة بطبيعتها للعمل فقط بدون systemd، والتعارض مع systemd مفيد بالفعل لأنه يمنع تثبيت elogind عن طريق الخطأ. من ناحية أخرى، في شكلها الحالي، تؤدي المحاولات عبر APT لتحديث التكوين من systemd إلى الإصدار الذي يحتوي على sysvinit وelogind إلى مع APT لا يعمل ولكن حتى لو تم القضاء على هذا العيب، فإن الانتقال من systemd إلى elogind يظل مستحيلا دون حذف بيئات المستخدم المثبتة بالفعل.
كان مطورو elogind قم بتكييف elogind للعمل فوق libpam-systemd القياسي، دون استخدام طبقة libpam-elogind الخاصة به. يتم إعاقة انتقال elogind إلى libpam-systemd بسبب عدم وجود دعم لمفهوم الشرائح، لكن مطوري elogind لا يريدون تحقيق الامتثال الكامل لواجهة برمجة التطبيقات (API) وتكرار جميع إمكانيات systemd تمامًا، نظرًا لأن elogind يوفر الحد الأدنى فقط وظيفة لتنظيم تسجيلات دخول المستخدم ولا تهدف إلى تكرار جميع أنظمة systemd الفرعية.
يجب حل المشكلات الفنية الموصوفة على مستوى التفاعل بين فريق الإصدار ومشرفي elogind وsystemd، لكن قائد المشروع اضطر للتدخل لأن الفرق لم تتمكن من الاتفاق، وتطور العمل المشترك إلى مواجهة وحل المشكلة. وصلت المشكلة إلى طريق مسدود، حيث كان كل جانب على حق بطريقته الخاصة. وفقًا لسام هارتمان، فإن الوضع يقترب من حالة تتطلب تصويتًا عامًا (GR، القرار العام)، حيث سيقرر المجتمع أنظمة بديلة لـ init ودعم sysvinit باستخدام elogind.
إذا صوت أعضاء المشروع على تنويع أنظمة init، فسيشارك جميع المشرفين في العمل معًا لحل هذه المشكلة أو سيتم تعيين مطورين محددين للعمل على هذه المشكلة ولن يتمكن المشرفون بعد ذلك من تجاهل نظام init بديل أو التزام الصمت أو تأخير العملية.
حاليا في المستودع بالفعل حزم 1033 التي توفر وحدات خدمة لـ systemd، ولكنها لا تتضمن نصوص init.d. لحل هذه المشكلة توفير ملفات الخدمة بشكل افتراضي، ولكن قم بإعداد معالج يقوم تلقائيًا بتحليل الأوامر من هذه الملفات وإنشاء نصوص init.d بناءً عليها.
إذا قرر المجتمع أن دبيان لديه ما يكفي من الدعم لنظام init واحد، لم يعد بإمكاننا القلق بشأن sysvinit وelogind والتركيز فقط على ملفات الوحدة وsystemd. سيؤثر هذا القرار سلبًا على المنافذ التي لا تستخدم Linux kernel (, и )، ولكن لا توجد مثل هذه المنافذ في الأرشيف الرئيسي حتى الآن وليس لها الحالة .
سيؤدي الارتباط بـ systemd أيضًا إلى زيادة صعوبة تغيير اتجاه التوزيع في المستقبل وسيحد من إجراء المزيد من التجارب في مجال التهيئة وإدارة الخدمة. يعد الحفاظ على elogind في شكل عمل أسهل بكثير من حذفه ثم محاولة إضافته مرة أخرى. كل خيار قرار له إيجابيات وسلبيات، لذا ستكون هناك حاجة إلى مناقشة كاملة لجميع الإيجابيات والسلبيات قبل التصويت.
المصدر: opennet.ru