バージョン文字列は VPN プラグインの機能を証明しない

バージョンの議論を機能の調査から分ける三つの問いとは、その機能を提供するはずなのはどのコンポーネントか、そのコンポーネントのどのバージョンが実際にインストールされているか、そしてその変更履歴が何と言っているかです。プラグインの番号だけでは、どれにも答えられません。魅力的な近道、つまり短縮版のバージョンをチュートリアルの最小値と比べる方法は、ディストリビューションのバージョン文字列が小数ではないため失敗します。比べる前に、何を比べているのかを決めてください。

その機能は NetworkManager に、その VPN プラグインに、下層のエンジンに、あるいは別のデスクトップフロントエンドにあるかもしれません。これは四つのプロジェクトであり、四つのリリース履歴があります。

四つのコンポーネント、四つのリリース履歴

目にするエディターは通常プラグインで、プラグインは OpenVPN のバイナリや WireGuard の実装といったエンジンを呼び出します。NetworkManager 自体が接続モデルを提供し、デスクトップフロントエンドが独自のフィールドを上に追加することもあります。機能はどれに現れてもおかしくなく、一つを更新しても他は更新されません。新しいエンジンは、インストール済みのエディターがエンジンの対応するオプションをインポートできる証拠にはなりません。

症状から始めます——フィールドがダイアログにないのか、インポート後に消えるのか、それとも存在するのに無視されるのか？ これらの観察は別々のコンポーネントを指し、別々の証拠を必要とします。

比べる前にバージョンを分解する

Debian のパッケージポリシーは、形式を epoch、upstream バージョン、パッケージングリビジョンと定義しています。まず epoch、次に upstream 部分、次にリビジョンを、小数の算術や単純なアルファベット順ではなく、パッケージマネージャー自身の順序規則で比較します。チルダはその部分の終わりを含め、あらゆるものより前に並ぶため、リリース候補が最終リリースに先行します。部分を分けて読むことが、比較を意味あるものにします。

0.8.999 が 0.9 に近く見えるような別の方式のための換算規則を発明しないでください。数字の近さは内容の証拠ではありません。

何がインストールされ、何になるのかを尋ねる

apt-cache policy は、指定した各パッケージについて、インストール済みのバージョン、候補、そしてそれぞれがどのリポジトリ由来かを報告します。エンジンとプラグインの両方について読み、短縮形ではなく完全な文字列を記録してください。ローカルのメタデータは古くなっていることがあり、候補バージョンは実行中のプロセスがそのビルドを読み込んだことを証明しません。アップグレード後にサービスを再起動していなければ、ディスク上のファイルと観察される動作は食い違うことがあります。

次に一致する変更履歴を読みます。パッケージングリビジョンは新しい upstream 番号を採らずにパッチを運ぶことがあり、まさにその場合にバージョンは変わらないように見えて動作が異なります。

その機能を所有するコンポーネントで証明する

インポートの問題では、ダイアログだけでなく、インストール済みプラグインの対応フィールドと保存された結果を調べます。ラベル、ネイティブなデータフィールド、エンジンの引数は一つの設定の三つの表現かもしれず、ファイルのインポートに成功したからといって各指示が残ったとは限りません。機能を正確に名指ししてください、たとえば、この指示を認証上の意味を保ったまま受け入れることです。

そのリリースの対応ビルドに統合がないなら、承認された更新経路か別のクライアントを選びます。別リリースのリポジトリを混ぜたり、見える番号を上げるためにアーカイブ済みのソースパッチを当てたりすることは、バージョンの議論を未対応のシステムと引き換えにする行為です。

役立つ報告は、ディストリビューション、完全なパッケージバージョン、アクティブな接続の所有者、必要なオプション、観察された保存動作を名指しします。それは再現可能な問いです。