ডিস্ট্রো নাম, glibc নাকি কম্পাইলার: ইনস্টলার কী যাচাই করে
আপনার ডেরিভেটিভ বাতিল করা একটি ইনস্টলার ডিস্ট্রো নাম, রানটাইম সংস্করণ বা কম্পাইলার পড়তে পারে। এর মধ্যে কেবল একটি-ই ঠিক করে বাইনারিটি চলতে পারবে কি না।
ইনস্টলার “unsupported distribution” ছাপে, আপনি একটি স্ট্রিং সম্পাদনা করেন, আর এটি চলতে থাকে যতক্ষণ না এক মিনিট পরে লোডার ত্রুটি নিয়ে ব্যর্থ হয়। এই ক্রমটিই লক্ষণীয় লক্ষণ: প্রথম ব্যর্থতা ছিল একটি শনাক্তকরণ যাচাই, আর দ্বিতীয়টি একটি সামঞ্জস্যের সীমা। এরা দুটি ভিন্ন সমস্যা যা কেবল একই টার্মিনালে দেখা দেয়। যাচাইটি সম্পাদনা করলে আপনি কেবল প্রথম থেকে দ্বিতীয়টিতে যেতে পারেন।
লক্ষণ: ইনস্টলার আপনার ডেরিভেটিভে থেমে যায়
যে স্ক্রিপ্ট একটি ডিস্ট্রিবিউশন নাম পড়ে এবং চালিয়ে যেতে অস্বীকার করে, সেটি আপনাকে বলছে যে এর লেখক আপনার ডেরিভেটিভ পরীক্ষা করেননি। এটি একটি সহায়তা-বিবৃতি, প্রযুক্তিগত সত্য নয়, এবং এটি প্রায়ই ভুল—এই অর্থে যে প্যাকেজটি ঠিকঠাক চলত।
ঝামেলা শুরু হয় যখন কাজের বাইরের সমাধানই পরিকল্পনা হয়ে যায়। একটি পরিচয় ফাইল বদলালে যাচাই পার হয়, আর প্যাকেজটি তখন বাস্তবে ইনস্টল করা রানটাইমের বিরুদ্ধে লোড হয়, বা লোড হতে ব্যর্থ হয়। সেখানে ব্যর্থ হলে আর কোনো পরিচয় সম্পাদনা কাজে আসবে না।
তাই কাজের কথা হলো—ইনস্টলার কোন প্রশ্নটি করেছিল তা খুঁজে বের করা, তারপর উত্তরটির কোনো গুরুত্ব থাকত কি না তা বের করা। এরা দুটি আলাদা তদন্ত, এবং কেবল দ্বিতীয়টিই পূর্বানুমান করে প্যাকেজটি চলবে কি না।
তিনটি সংস্করণ যাকে মানুষ সিস্টেম সংস্করণ বলে
ডিস্ট্রিবিউশন রিলিজ একটি প্যাকেজকৃত পরিবেশের নাম দেয়। C লাইব্রেরি সংস্করণ একটি রানটাইম বাস্তবায়ন ও তার রিলিজের নাম দেয়। কম্পাইলার সংস্করণ একটি টুলচেইনের নাম দেয়। কথাবার্তায় মানুষ তিনটিকেই “সিস্টেম সংস্করণ” বলে, কিন্তু ইনস্টলারে এরা বিনিময়যোগ্য নয়।
cat /etc/os-release ldd --version | head -1 gcc --version | head -1 uname -m
পূর্বনির্মিত একটি অ্যাপ্লিকেশন সেই রানটাইম প্রত্যাশা করে যা এটি লিংক করার সময় উপস্থিত ছিল। হোস্টে কম্পাইলার বদলালে এটি পুনরায় লিংক হয় না, আর নতুন টুলচেইন বাইনারিটি যে লোডার প্রতীক চায় তাতে কিছুই বদলায় না। আর্কিটেকচার আবার আলাদাভাবে গুরুত্বপূর্ণ, কারণ 64-বিট সিস্টেমে একটি 32-বিট প্যাকেজ এমন কারণে ব্যর্থ হয় যা কোনো সংস্করণ স্ট্রিং ব্যাখ্যা করে না।
চারটি আউটপুট প্রতিবেদনের সাথে রাখুন। এগুলো সংগ্রহ করতে দশ সেকেন্ড লাগে এবং রক্ষণাবেক্ষণকারী যে প্রশ্নগুলো ইমেইলে করতেন তার বেশিরভাগের উত্তর দেয়।
যাচাই নয়, ত্রুটিটি পড়ুন
প্রথম লঞ্চ ত্রুটিই প্রমাণ। অনুপস্থিত শেয়ার্ড অবজেক্ট, বা লোডার যে প্রতীক সংস্করণ পূরণ করতে পারে না, সে সম্পর্কে বার্তা হলো রানটাইম নির্ভরতার সমস্যা। যে বার্তা ডিস্ট্রিবিউশন নামটি পুনরাবৃত্তি করে, সেটি আবার শনাক্তকরণ যাচাই, ভিন্ন জায়গায়।
ডাইনামিক লিংকারের ডকুমেন্টেশন ব্যাখ্যা করে লাইব্রেরি অনুসন্ধান কীভাবে কাজ করে এবং লোডার কোথায় খোঁজে। ডিস্ট্রিবিউশন লেবেল বদলালে সেই অনুসন্ধান পথে কোনো ডিরেক্টরি যোগ হয় না, তাই দ্বিতীয় ব্যর্থতাটি প্রথমটির সাথে অসম্পর্কিত মনে হয়।
ডাউনলোড করা এক্সিকিউটেবলে ldd ব্যবহার করাকে সাধারণ প্রথম ধাপ হিসেবে নেবেন না। এর নিজের ম্যানুয়াল সতর্ক করে যে কিছু পরিস্থিতিতে এটি প্রোগ্রামটি চালাতে পারে, এবং অবিশ্বস্ত ইনস্টলার চালানো ঠিক সেই ক্ষেত্রটিই যার বিষয়ে সেই সতর্কতা।
স্ট্রিং সম্পাদনা কেন সাহায্য করে না
অপারেটিং সিস্টেম পরিচয় জাল করা বদলে দেয় মেশিনের প্রতিটি প্রোগ্রাম নিজেকে কীভাবে দেখে। প্যাকেজ ম্যানেজার, সহায়তা সরঞ্জাম ও অন্যান্য অ্যাপ্লিকেশন একই ফাইল পড়ে, এবং একটি ইনস্টলারকে সন্তুষ্ট করা মান মাস খানেক পরে অন্য কিছুকে বিভ্রান্ত করতে পারে।
হোস্ট লাইব্রেরিগুলো অন্য ডিস্ট্রিবিউশনের ফাইল দিয়ে প্রতিস্থাপন আরও খারাপ। এটি অসম্পর্কিত সফটওয়্যার ভাঙতে পারে, প্যাকেজ ম্যানেজারের কাছে অদৃশ্য, এবং এমন একটি রক্ষণাবেক্ষণ পরিকল্পনা দরকার যা কেউ লিখে রাখে না। এসব পরিবর্তন একটি কঠোর ইনস্টলার দিয়ে ন্যায্যতা পায় না।
যদি যাচাই সত্যিই শনাক্তকরণের ত্রুটি হয়, রক্ষণাবেক্ষণকারী তা নিশ্চিত করে সমর্থিত সংশোধন বর্ণনা করতে পারেন। যদি ত্রুটি না হয়, সমর্থিত পথ হলো আপনার প্ল্যাটফর্মের জন্য একটি বিল্ড, আর স্ট্রিং সম্পাদনার কারণে সেই উত্তর বদলায় না।
এমন প্রতিবেদন লিখুন যা নিয়ে রক্ষণাবেক্ষণকারী কাজ করতে পারেন
ডিস্ট্রিবিউশন ও রিলিজ, আর্কিটেকচার, VPN রিলিজ, যে সুনির্দিষ্ট শর্ত প্রত্যাখ্যাত হয়েছিল, এবং যদি সেখানে পৌঁছে থাকেন তবে প্রথম রানটাইম ত্রুটি লিখে রাখুন। আপনি কিছু বদলেছেন কি না উল্লেখ করুন, কারণ পরিবর্তিত সিস্টেম থেকে আসা প্রতিবেদন আলাদা প্রতিবেদন।
মূল ইনস্টলার অপরিবর্তিত রাখুন এবং এটি এড়িয়ে যাওয়ার বদলে যাচাইটি বর্ণনা করুন। এই পার্থক্যই রক্ষণাবেক্ষণকারীকে অতি সংকীর্ণ শনাক্তকরণ নিয়মকে প্রকৃত বাইনারি সামঞ্জস্যের সীমা থেকে আলাদা করতে দেয়, যারা দুই ভিন্ন বাগ ও দুই ভিন্ন সমাধান।
যদি উত্তর আসে যে আপনার প্ল্যাটফর্ম সমর্থিত নয়, সেটি ব্যবহারযোগ্য ফলাফল। এটি আপনাকে বলে সমর্থিত বিল্ড খুঁজতে, যে পরিচয় ফাইলগুলো কখনোই সমস্যা ছিল না সেগুলোতে আরেকটি সন্ধ্যা নষ্ট করার বদলে।