DNF はプロキシ経由で動く。GNOME Software はなぜ動かないのか

DNF は不平も言わずにパッケージをダウンロードします。GNOME Software はカタログを表示し、何かをインストールしようとするとそこで止まります。グラフィカルアプリがプロキシを単に無視している、と結論づけたくなります。しかし別の可能性があります。プロキシの情報が、ダウンロードを実行するコンポーネントにそもそも届いていないのです。

受け渡しをたどる

GNOME Software と、端末で入力したコマンドは、同じ設定経路を持っていません。PackageKit のプロキシのドキュメントは、デスクトップの設定を読み取り、それをデーモンに中継するセッションプロセスについて説明しています。GNOME では gnome-software が GSettings を読み、PackageKit のプロキシ設定インターフェースを呼び出します。

次にデーモンが、該当するセッションの設定をパッケージバックエンドに渡します。つまり、DNF の要求が成功したことは、プロキシがその DNF 呼び出しを処理できる証拠です。しかし、デスクトップセッションが同じ設定を PackageKit に登録した証拠にはなりません。

3 つの有用な問い

1. どの操作が失敗したのか。 カタログデータの表示、メタデータの更新、パッケージのダウンロードは別々の操作です。実際にエラーを出す操作を記録してください。
2. セッションのプロキシは登録されたのか。 デスクトップの有効なプロキシ設定と、PackageKit が報告するエラーを調べます。プロキシの設定に失敗することと、ダウンロード中にプロキシが 407 を返すことは別です。
3. どのバージョンがその設定を所有しているのか。 PackageKit は時間とともに変わってきました。Fedora 25 についての回答からコピーした設定キーは、古いバックエンドや、もはや当てはまらない不具合を説明しているかもしれません。

端末で export した変数は、この受け渡しを確認する確実な代替にはなりません。デーモンは export を入力したシェルの子ではなく、グラフィカルログインでは環境が異なることがあります。

修正は、問題を所有するコンポーネントに結びつけたままにしてください。デスクトップの設定が誤っているなら、その設定を直します。登録が失敗するなら、そのエラーとバージョン情報を残します。プロキシがダウンロードを拒否するなら、認証や宛先の方針を調べます。リポジトリのファイルを一斉に編集すると、区別が見えにくくなり、コマンドラインとグラフィカルの設定を保守しづらくなります。