DNF עובד דרך ה-proxy. אז למה GNOME Software לא?
GNOME Software מעביר את הגדרות ה-proxy של הסשן ל-PackageKit; פקודת DNF שעובדת אינה מוכיחה שההורדה הגרפית משתמשת באותה תצורה.
DNF מוריד חבילות בלי תלונות. GNOME Software מציג את הקטלוג ואז נעצר כשמבקשים ממנו להתקין משהו. מפתה להסיק שהיישום הגרפי פשוט מתעלם מה-proxy. יש אפשרות אחרת: המידע על ה-proxy מעולם לא הגיע לרכיב שמבצע את ההורדה.
עקבו אחר ההעברה
ל-GNOME Software ולפקודה שהקלדתם במסוף אין אותו נתיב תצורה. התיעוד של PackageKit בנושא proxy מתאר תהליך סשן שקורא את הגדרות שולחן העבודה ומעביר אותן ל-daemon. ב-GNOME, gnome-software קורא את GSettings וקורא לממשק הגדרת ה-proxy של PackageKit.
לאחר מכן ה-daemon מספק את הגדרות הסשן המתאים ל-backend החבילות שלו. כלומר, בקשת DNF מוצלחת מוכיחה שה-proxy יכול לשרת את קריאת ה-DNF הזו. היא אינה מוכיחה שסשן שולחן העבודה רשם את אותן הגדרות ב-PackageKit.
שלוש שאלות שימושיות
- איזו פעולה נכשלה? צפייה בנתוני הקטלוג, רענון מטא-נתונים והורדת חבילה הן פעולות שונות. תעדו את זו שמייצרת בפועל שגיאה.
- האם ה-proxy של הסשן נרשם? בדקו את תצורת ה-proxy האפקטיבית של שולחן העבודה ואת השגיאות ש-PackageKit מדווח. כישלון בהגדרת ה-proxy שונה מ-proxy שמחזיר 407 במהלך ההורדה.
- איזו גרסה מחזיקה בהגדרה? PackageKit השתנה עם הזמן. מפתח תצורה שהועתק מתשובה על Fedora 25 עשוי לתאר backend ישן או באג שכבר אינו רלוונטי.
משתנים מיוצאים במסוף אינם תחליף אמין לבדיקת ההעברה הזו. ה-daemon אינו בן של ה-shell שבו הקלדתם את ה-export, ולכניסה גרפית יכול להיות סביבה שונה.
השאירו כל תיקון קשור לרכיב שמחזיק בבעיה. אם תצורת שולחן העבודה שגויה, תקנו את התצורה הזו. אם הרישום נכשל, שמרו את השגיאה ופרטי הגרסה. אם ה-proxy דוחה את ההורדה, בדקו את מדיניות האימות או היעד שלו. עריכת כל קובצי המאגר בבת אחת עלולה לטשטש את ההבחנה ולהקשות על תחזוקת תצורות שורת הפקודה והגרפיקה.