‏DNF بسته‌ها را بدون هیچ شکایتی بارگیری می‌کند. ‏GNOME Software فهرست را نشان می‌دهد و سپس وقتی می‌خواهید چیزی نصب کنید متوقف می‌شود. وسوسه‌انگیز است که نتیجه بگیریم برنامه گرافیکی به‌سادگی پروکسی‌ها را نادیده می‌گیرد. احتمالی دیگر هم وجود دارد: اطلاعات پروکسی هرگز به مؤلفه‌ای که بارگیری را انجام می‌دهد نرسیده است.

این تحویل را دنبال کنید

‏GNOME Software و فرمانی که در ترمینال وارد کرده‌اید مسیر پیکربندی یکسانی ندارند. مستندات پروکسی PackageKit فرایندی درون نشست را توصیف می‌کند که تنظیمات میزکار را می‌خواند و آن‌ها را به دیمن منتقل می‌کند. در GNOME، برنامه gnome-software تنظیمات GSettings را می‌خواند و رابط تنظیم پروکسی PackageKit را فراخوانی می‌کند.

سپس دیمن تنظیمات نشست مناسب را به موتور بسته خود می‌دهد. این یعنی یک درخواست موفق DNF ثابت می‌کند که پروکسی می‌تواند آن فراخوانی DNF را پاسخ دهد. اما ثابت نمی‌کند که نشست میزکار همان تنظیمات را در PackageKit ثبت کرده است.

سه پرسش مفید

  1. کدام عملیات شکست خورد؟ دیدن داده‌های فهرست، تازه‌سازی فراداده‌ها و بارگیری یک بسته عملیات‌های متفاوتی هستند. همان عملیاتی را ثبت کنید که واقعاً خطا تولید می‌کند.
  2. آیا پروکسی نشست ثبت شد؟ پیکربندی مؤثر پروکسی میزکار و خطاهای گزارش‌شده PackageKit را بررسی کنید. ناکامی در تنظیم پروکسی با پروکسی‌ای که در هنگام بارگیری 407 برمی‌گرداند متفاوت است.
  3. کدام نسخه مالک این تنظیم است؟ PackageKit در گذر زمان تغییر کرده است. کلید پیکربندی‌ای که از پاسخی درباره Fedora 25 کپی شده ممکن است موتور قدیمی یا اشکالی را توصیف کند که دیگر اعمال نمی‌شود.

متغیرهای صادرشده در ترمینال جایگزین قابل اعتمادی برای بررسی این تحویل نیستند. دیمن فرزند پوسته‌ای نیست که export را در آن تایپ کرده‌اید، و ورود گرافیکی می‌تواند محیط متفاوتی داشته باشد.

هر اصلاحی را به مؤلفه‌ای که مالک مشکل است گره بزنید. اگر پیکربندی میزکار نادرست است، همان پیکربندی را اصلاح کنید. اگر ثبت شکست می‌خورد، خطا و اطلاعات نسخه آن را نگه دارید. اگر پروکسی بارگیری را رد می‌کند، سیاست احراز هویت یا مقصد آن را بررسی کنید. ویرایش همه فایل‌های مخزن به‌طور همزمان می‌تواند این تمایز را پنهان کند و نگهداری پیکربندی خط فرمان و پیکربندی گرافیکی را دشوارتر سازد.

مقالات مرتبط