Aptの依存関係がどのように処理されるか、またはdebファイルに対してどのように定義されるかを知りたいです~
(構文がどこに定義されているのかわかりません)。
python3
依存関係制約を持つUbuntu(Focal)メタパッケージに関連する依存関係の問題を発見しましたpython3.8 >= 3.8.2-1~
。ここ)。
python3.8
パッケージバージョンがアルファベット順にソートされるように定義されていると思いますが、Ubuntuフォーカスを確認してみるとアルファベット順にソートされたバージョンはありませんでしたが、Ubuntu Focalの依存関係が破損していると推定される>=
3.8.2-1~
バージョンが1つありました(3.8.10-0ubuntu1~20.04.4
彼らはそうではありません~
)または依存関係に特別な意味があります。
このトピックについて私が見つけることができる唯一の文書はDebianの文書です。パッケージ間の関係宣言。ただし、これは~
ORパターンの一致には言及しません。
~
もしそうなら、.deb依存関係の末尾の意味は何ですか?
答え1
これ文書制御Version
フィールドの状態(全体のアルゴリズムについてはページを参照):
数字以外の文字だけで構成される各文字列の最初の部分を識別することから始めます。これら2つの部分(そのうちの1つは空にすることができます)は語彙的に比較されます。違いが見つかると返されます。
語彙比較は、変更されたASCII値を比較して、すべての文字がすべての非文字よりも前に並べ替えられ、チルダが他のものよりも前に(セクションの終わりに)整列されるようにします。たとえば、次のセクションは、最も早いものから最新のものまでソートされます。、、、、空
~~
のセクション、。~~a
~
a
チルダに追加された脚注:
一般的な用途の1つ
~
は上流の試用版です。たとえば、1.0~beta1~svn1245
前のソート1.0~beta1
、以前のソートです1.0
。
答え2
バージョンのチルダ文字を記述します。バージョンポリシーセクションで。デフォルトでは、チルダは何よりも先にソートされます。
したがって、連続して2つのチルダがない限り、チルダ自体で始まるサフィックス付きのバージョン(バックポートなど)を含む、で始まるすべての>= 3.8.2-1~
バージョンで十分です。実際、これらの依存関係(バージョンの末尾にチルダがある(Debianリビジョンを含む))は、バックポーティングを容易にするためによく使用されます。3.8.2-1
3.8.2-1~bpo
これがまさにあなたの問題であり、Debianポリシーでは解決されないので、より詳細に議論する価値があります。一般的なバージョンの依存関係は次のとおりで、python3.8 >= 3.8.2-1
パッケージバージョン3.8.2-1以降が必要ですpython3.8
。 Python 3.8の以降のアップストリームバージョンは、このパッケージの将来のDebianバージョン(3.8.2-2または3.8.2-1ubuntu1など)と同様に、この要件を満たしています。ただし、バックポートされたバージョンは3.8.2-1〜bpo10 + 1形式です。チルダが空の文字列の前にあるため、3.8.2-1からbpo10 + 1は3.8.2より小さいと見なされます。 -1.したがって、この形式のバージョン依存性を持つパッケージをバックポートするには、その依存関係を変更する必要があり、これはバックポートが元のパッケージにできるだけ近いという一般的な規則に違反します。
したがって、バージョン指定された依存関係からバージョンの最後の文字にチルダを追加すると、依存関係が少し軽減されるのに役立ちます。これにより、同じプレフィックスとチルダで区切られたサフィックスを持つバージョンがバージョンの依存関係を満たすことができます。これは反対ですプレリリース版のチルダ使用履歴、その結果のバージョンできない最終リリースの厳格なバージョン依存関係を満たしています。
(質問に記載されているように、Debianのリビジョンを含むバージョン番号の最後の文字としてチルダを参照してください。できないアップストリームのプレリリースが許可されています。これは3.8.2〜pre1-1に似ており、3.8.2-1〜より小さいです。 )
バージョンは語彙順にソートされず、コンポーネントごとに、可能であれば数字順に、そうでなければ語彙順にソートされます。したがって、3.8.10-0ubuntu1〜20.04.4はこの関係を満たしています。 10 が 2 より大きいので、依存関係が満たされ、比較がここで終了します。