سیم ہارٹ مین، ڈیبین پروجیکٹ لیڈر، تقسیم کے حصے کے طور پر ایلوگائنڈ پیکج کی ترسیل سے وابستہ اختلافات کو سمجھنے کے لیے۔ جولائی میں، ریلیز کی تیاری کے لئے ذمہ دار ٹیم ٹیسٹنگ برانچ میں elogind کی شمولیت، کیونکہ یہ پیکیج libsystemd سے متصادم ہے۔
کہ یاد سسٹم ڈی کو انسٹال کیے بغیر گنووم کو چلانے کے لیے درکار انٹرفیس فراہم کرتا ہے۔ اس پروجیکٹ کی بنیاد سسٹمڈ لاگ ان کے کانٹے کے طور پر رکھی گئی تھی، جسے الگ پیکج میں رکھا گیا تھا اور اسے سسٹمڈ اجزاء کے پابند ہونے سے آزاد کیا گیا تھا۔ دیگر چیزوں کے علاوہ، elogind libelogind لائبریری کا اپنا ورژن فراہم کرتا ہے، جو libsystemd میں پیش کردہ متعدد افعال کو انجام دیتا ہے اور انسٹالیشن کے دوران اس لائبریری کی جگہ لے لیتا ہے۔
بلاک کرنے کی وجوہات سسٹمڈ پیکج کے ساتھ تصادم اور libsystemd کو متبادل libelogind سے تبدیل کرنے کا خطرہ تھا، جو ABI کی سطح پر سورس لائبریری سے مکمل طور پر مطابقت نہیں رکھتا ہے۔
پیکیج elogind کو سسٹمڈ لائبریریوں سے متصادم قرار دیتا ہے، لیکن یہ فطری طور پر صرف systemd کے بغیر کام کرنے کے لیے ڈیزائن کیا گیا ہے، اور systemd کے ساتھ متصادم ہونا دراصل فائدہ مند ہے کیونکہ یہ elogind کو غلطی سے انسٹال ہونے سے روکتا ہے۔ دوسری طرف، اس کی موجودہ شکل میں، APT کے ذریعے sysvinit اور elogind کے ساتھ سسٹمڈ سے ورژن میں کنفیگریشن کو اپ ڈیٹ کرنے کی کوششوں کے نتیجے میں اے پی ٹی کے ساتھ کام نہیں کر رہا ہے۔ لیکن یہاں تک کہ اگر اس کوتاہی کو ختم کر دیا جائے تو، پہلے سے نصب شدہ صارف کے ماحول کو حذف کیے بغیر systemd سے elogind میں منتقلی ناممکن ہے۔
ایلوگائنڈ ڈویلپر تھے۔ اپنی libpam-elogind پرت کا استعمال کیے بغیر، معیاری libpam-systemd کے اوپر کام کرنے کے لیے elogind کو ڈھال لیں۔ elogind کی libpam-systemd میں منتقلی سلائسز کے تصور کے لیے تعاون کی کمی کی وجہ سے رکاوٹ ہے، لیکن elogind کے ڈویلپر API کے ساتھ مکمل تعمیل حاصل نہیں کرنا چاہتے اور systemd کی تمام صلاحیتوں کو بالکل دہرانا نہیں چاہتے، کیونکہ elogind صرف کم سے کم فراہم کرتا ہے۔ صارف کے لاگ ان کو منظم کرنے کی فعالیت اور اس کا مقصد تمام سسٹمڈ سب سسٹمز کو نقل کرنا نہیں ہے۔
بیان کردہ تکنیکی مسائل کا حل ریلیز ٹیم اور ایلوگائنڈ اور سسٹمڈ مینٹینرز کے درمیان بات چیت کی سطح پر حل کیا جانا چاہیے، لیکن پروجیکٹ لیڈر کو مداخلت کرنے پر مجبور کیا گیا کیونکہ ٹیمیں متفق نہ ہو سکیں، مشترکہ کام تصادم کی شکل اختیار کر گیا اور اس مسئلے کا حل مسئلہ ایک آخری انجام کو پہنچ گیا، جس میں ہر فریق اپنے اپنے طریقے سے درست تھا۔ سیم ہارٹ مین کے مطابق، صورت حال ایک ایسی ریاست کے قریب پہنچ رہی ہے جس کے لیے عام ووٹ (GR، جنرل ریزولوشن) کی ضرورت ہوتی ہے، جس میں کمیونٹی انیٹ کے لیے متبادل نظام اور ایلوگنڈ کے ساتھ sysvinit کی حمایت کا فیصلہ کرے گی۔
اگر پروجیکٹ ممبران init سسٹم کو متنوع بنانے کے لیے ووٹ دیتے ہیں، تو تمام مینٹینرز اس مسئلے کو حل کرنے کے لیے مل کر کام کرنے میں شامل ہوں گے یا مخصوص ڈویلپرز کو اس مسئلے پر کام کرنے کے لیے تفویض کیا جائے گا اور مینٹینرز اب متبادل init سسٹم کو نظر انداز نہیں کر سکیں گے، خاموش رہیں گے، یا عمل میں تاخیر.
فی الحال پہلے سے ہی ذخیرہ میں ہے۔ 1033 پیکجز جو systemd کے لیے سروس یونٹ فراہم کرتے ہیں، لیکن init.d اسکرپٹ شامل نہیں کرتے۔ اس مسئلے کو حل کرنے کے لیے سروس فائلوں کو بطور ڈیفالٹ فراہم کریں، لیکن ایک ہینڈلر تیار کریں جو خود بخود ان فائلوں سے کمانڈز کو پارس کرے اور ان کی بنیاد پر init.d اسکرپٹ تیار کرے۔
اگر کمیونٹی فیصلہ کرتی ہے کہ Debian کو سنگل init سسٹم کے لیے کافی سپورٹ حاصل ہے، تو ہم مزید sysvinit اور elogind کی فکر نہیں کر سکتے اور صرف یونٹ فائلوں اور systemd پر توجہ مرکوز کر سکتے ہیں۔ یہ فیصلہ ان بندرگاہوں پر منفی اثر ڈالے گا جو لینکس کرنل (, и )، لیکن مرکزی آرکائیو میں ابھی تک ایسی کوئی بندرگاہیں نہیں ہیں اور ان کی حیثیت نہیں ہے۔ .
Systemd کا پابند ہونا مستقبل میں تقسیم کی سمت کو تبدیل کرنا بھی زیادہ مشکل بنا دے گا اور ابتدائی اور سروس مینجمنٹ کے میدان میں مزید تجربات کو محدود کر دے گا۔ elogind کو کام کرنے والی شکل میں برقرار رکھنا اسے حذف کرنے اور پھر اسے دوبارہ شامل کرنے کی کوشش کرنے سے کہیں زیادہ آسان ہے۔ ہر فیصلے کے آپشن کے فوائد اور نقصانات ہوتے ہیں، اس لیے ووٹنگ سے پہلے تمام نفع اور نقصانات پر مکمل بحث کی ضرورت ہوگی۔
ماخذ: opennet.ru