سام هارتمان، ديبين پروجيڪٽ ليڊر، تقسيم جي حصي طور elogind پيڪيج جي ترسيل سان لاڳاپيل اختلافن کي سمجهڻ لاءِ. جولاء ۾، ٽيم رليز تيار ڪرڻ جو ذميوار آهي ٽيسٽنگ برانچ ۾ elogind جي شموليت، ڇاڪاڻ ته هي پيڪيج libsystemd سان ٽڪراءُ ڪري ٿو.
پگهار ته سسٽم ڊي کي انسٽال ڪرڻ کان سواءِ GNOME کي هلائڻ لاءِ گهربل انٽرفيس مهيا ڪري ٿو. پروجيڪٽ سسٽمڊ-لاگنڊ جي ڪانٽو جي طور تي ٺهرايو ويو، هڪ الڳ پيڪيج ۾ رکيل آهي ۽ سسٽمڊ اجزاء کي پابند ڪرڻ کان آزاد ڪيو ويو. ٻين شين جي وچ ۾، elogind libelogind لائبريري جو پنهنجو نسخو مهيا ڪري ٿو، جيڪو libsystemd ۾ پيش ڪيل ڪيترن ئي ڪمن تي وٺندو آهي ۽ انسٽاليشن دوران هن لائبريري کي تبديل ڪري ٿو.
بلاڪ ڪرڻ جا سبب سسٽمڊ پيڪيج سان تڪرار ۽ libsystemd کي متبادل libelogind سان تبديل ڪرڻ جو خطرو هو، جيڪو ABI سطح تي اصل لائبريري سان مڪمل طور تي غير مطابقت رکي ٿو.
پيڪيج ايلوگنڊ کي سسٽمڊ لائبريرين سان تڪرار جي طور تي ليبل ڪري ٿو، پر اهو فطري طور تي صرف سسٽمڊ کان سواء ڪم ڪرڻ لاء ٺهيل آهي، ۽ سسٽم ڊي سان تڪرار اصل ۾ فائدي وارو آهي ڇاڪاڻ ته اهو ايلوگنڊ کي غلطي سان نصب ٿيڻ کان روڪي ٿو. ٻئي طرف، ان جي موجوده شڪل ۾، APT جي ذريعي ڪوشش ڪئي وئي ته سسٽم ڊي کان ورزن تائين ترتيبن کي اپڊيٽ ڪرڻ لاء sysvinit ۽ elogind نتيجو APT ڪم نه ڪندي. پر جيتوڻيڪ هن نقص کي ختم ڪيو وڃي، سسٽم ڊي کان ايلوگنڊ تائين منتقلي اڳ ۾ ئي نصب ٿيل صارف ماحول کي ختم ڪرڻ کان سواء ناممڪن رهي ٿي.
Elogind ڊولپر هئا معياري libpam-systemd جي چوٽي تي ڪم ڪرڻ لاءِ elogind کي ترتيب ڏيو، ان جي پنھنجي libpam-elogind پرت کي استعمال ڪرڻ کان سواء. elogind جي libpam-systemd ڏانهن منتقلي سلائسن جي تصور جي حمايت جي کوٽ جي ڪري رڪاوٽ آهي، پر elogind جا ڊولپر API سان مڪمل تعميل حاصل ڪرڻ نٿا چاهين ۽ سسٽم جي سڀني صلاحيتن کي بلڪل ورجائي ٿو، ڇو ته elogind صرف گهٽ ۾ گهٽ مهيا ڪري ٿو. صارف لاگ ان کي منظم ڪرڻ لاءِ ڪارڪردگي ۽ سڀني سسٽمڊ سب سسٽم کي نقل ڪرڻ جو مقصد ناهي.
بيان ڪيل ٽيڪنيڪل مسئلن جو حل ڇڏڻ واري ٽيم ۽ ايلوگنڊ ۽ سسٽم جي سنڀال ڪندڙن جي وچ ۾ رابطي جي سطح تي حل ڪيو وڃي، پر پروجيڪٽ ليڊر کي مداخلت ڪرڻ تي مجبور ڪيو ويو ڇو ته ٽيمون متفق نه ٿي سگهيا، گڏيل ڪم تڪرار ۾ ترقي ڪئي ۽ ان جي حل لاء. مسئلو ختم ٿي ويو، جنهن ۾ هر طرف پنهنجي طريقي سان صحيح هو. سام هارٽمن جي مطابق، صورتحال هڪ رياست جي ويجهو اچي رهي آهي جنهن کي عام ووٽ (GR، جنرل ريزوليوشن) جي ضرورت آهي، جنهن ۾ ڪميونٽي انٽيٽ لاءِ متبادل نظام تي فيصلو ڪندي ۽ ايلوگنڊ سان sysvinit جي حمايت ڪندي.
جيڪڏهن پروجيڪٽ جا ميمبر init سسٽم کي متنوع ڪرڻ لاءِ ووٽ ڏين ٿا، سڀئي سنڀاليندڙ هن مسئلي کي حل ڪرڻ لاءِ گڏجي ڪم ڪرڻ ۾ شامل هوندا يا مخصوص ڊولپرز کي هن مسئلي تي ڪم ڪرڻ لاءِ مقرر ڪيو ويندو ۽ سنڀاليندڙ هاڻي متبادل شروعاتي نظام کي نظرانداز ڪرڻ جي قابل نه هوندا، خاموش رهندا، يا عمل کي دير ڪرڻ.
في الحال اڳ ۾ ئي مخزن ۾ 1033 پيڪيجز جيڪي سسٽم ڊي لاءِ سروس يونٽ مهيا ڪن ٿا، پر ان ۾ شامل نه آهن init.d اسڪرپٽ. هن مسئلي کي حل ڪرڻ لاء ڊفالٽ طور سروس فائلون فراهم ڪريو، پر ھڪڙو ھينڊلر تيار ڪريو جيڪو پاڻمرادو انھن فائلن مان ڪمانڊ پارس ڪري ۽ انھن جي بنياد تي init.d اسڪرپٽ ٺاھيو.
جيڪڏهن ڪميونٽي اهو فيصلو ڪري ٿي ته ديبين وٽ هڪ واحد شروعاتي سسٽم لاءِ ڪافي مدد آهي، اسان هاڻي sysvinit ۽ elogind بابت پريشان نه ٿا ڪري سگهون ۽ صرف يونٽ فائلن ۽ سسٽم تي ڌيان ڏئي سگهون ٿا. اهو فيصلو انهن بندرگاهن تي منفي اثر وجهندو جيڪي لينڪس ڪنيل استعمال نٿا ڪن (, и )، پر مکيه آرڪائيو ۾ اڃا تائين اهڙا بندرگاهن موجود نه آهن ۽ انهن جي حيثيت نه آهي .
سسٽم ڊي تي پابند پڻ مستقبل ۾ تقسيم جي هدايت کي تبديل ڪرڻ ۾ تمام گهڻو ڏکيو ٿيندو ۽ شروعات ۽ خدمت جي انتظام جي ميدان ۾ وڌيڪ تجربن کي محدود ڪندو. Elogind کي ڪم ڪرڻ واري فارم ۾ برقرار رکڻ ان کي حذف ڪرڻ ۽ ان کي ٻيهر شامل ڪرڻ جي ڀيٽ ۾ تمام آسان آهي. ھر فيصلي جي اختيار ۾ نفعو ۽ نقصان آھي، تنھنڪري ووٽنگ کان پھريائين سڀني نفعو ۽ نقصان جي مڪمل بحث جي ضرورت پوندي.
جو ذريعو: opennet.ru