DNF প্রক্সি দিয়ে কাজ করে। GNOME Software কেন করে না?

DNF কোনো অভিযোগ ছাড়াই প্যাকেজ ডাউনলোড করে। GNOME Software ক্যাটালগ দেখায়, তারপর আপনি কিছু ইনস্টল করতে বললে থেমে যায়। গ্রাফিক্যাল অ্যাপটি কেবল প্রক্সি উপেক্ষা করে বলে সিদ্ধান্তে আসা সহজ। আরেকটি সম্ভাবনা আছে: প্রক্সির তথ্য কখনো সেই কম্পোনেন্টে পৌঁছায়নি যা ডাউনলোড করছে।

হস্তান্তরটি অনুসরণ করুন

GNOME Software এবং আপনি টার্মিনালে যে কমান্ড দিয়েছেন, তাদের কনফিগারেশনের পথ এক নয়। PackageKit-এর প্রক্সি ডকুমেন্টেশন একটি সেশন প্রক্রিয়ার কথা বলে যা ডেস্কটপ সেটিংস পড়ে ডেমনকে পাঠায়। GNOME-এ gnome-software GSettings পড়ে এবং PackageKit-এর প্রক্সি-সেটিং ইন্টারফেস ডাকে।

এরপর ডেমন সংশ্লিষ্ট সেশনের সেটিংস তার প্যাকেজিং ব্যাকএন্ডে সরবরাহ করে। এর মানে একটি সফল DNF অনুরোধ প্রমাণ করে প্রক্সি সেই DNF কলটি পরিবেশন করতে পারে। এটি প্রমাণ করে না যে ডেস্কটপ সেশন একই সেটিংস PackageKit-এ নিবন্ধিত করেছে।

তিনটি উপকারী প্রশ্ন

1. কোন কাজটি ব্যর্থ হয়েছে? ক্যাটালগ ডেটা দেখা, মেটাডেটা রিফ্রেশ করা এবং প্যাকেজ ডাউনলোড করা ভিন্ন ভিন্ন কাজ। যেটি সত্যিই ত্রুটি দেয় সেটি লিপিবদ্ধ করুন।
2. সেশন প্রক্সি নিবন্ধিত হয়েছে কি? ডেস্কটপের কার্যকর প্রক্সি কনফিগারেশন এবং PackageKit-এর জানানো ত্রুটিগুলো পরীক্ষা করুন। প্রক্সি সেট করতে ব্যর্থ হওয়া আর ডাউনলোডের সময় প্রক্সির 407 ফেরানো ভিন্ন বিষয়।
3. কোন সংস্করণ সেটিংটির মালিক? PackageKit সময়ের সাথে বদলেছে। Fedora 25-এর উত্তর থেকে কপি করা কনফিগারেশন কী পুরনো ব্যাকএন্ড বা আর প্রযোজ্য নয় এমন বাগ বর্ণনা করতে পারে।

টার্মিনালের এক্সপোর্ট করা ভেরিয়েবল এই হস্তান্তর যাচাইয়ের নির্ভরযোগ্য বিকল্প নয়। ডেমন আপনি export টাইপ করা শেলের সন্তান নয়, এবং গ্রাফিক্যাল লগইনের পরিবেশ ভিন্ন হতে পারে।

যেকোনো সমাধান সমস্যার মালিক কম্পোনেন্টের সঙ্গে যুক্ত রাখুন। ডেস্কটপ কনফিগারেশন ভুল হলে সেই কনফিগারেশন ঠিক করুন। নিবন্ধন ব্যর্থ হলে তার ত্রুটি ও সংস্করণের তথ্য সংরক্ষণ করুন। প্রক্সি ডাউনলোড প্রত্যাখ্যান করলে তার প্রমাণীকরণ বা গন্তব্য নীতি তদন্ত করুন। একসঙ্গে সব রিপজিটরি ফাইল সম্পাদনা করলে পার্থক্যটি অস্পষ্ট হতে পারে এবং কমান্ড-লাইন ও গ্রাফিক্যাল কনফিগারেশন রক্ষণাবেক্ষণ কঠিন হয়ে পড়ে।