☰

/etc/apt/sources.list.d が /etc/apt/sources.list よりも優れている点は何ですか?

tag-icon • tag-icon linux apt etc
/etc/apt/sources.list.d が /etc/apt/sources.list よりも優れている点は何ですか?

この質問は以前にもされたことがあることは知っていますが、「カスタム追加がはっきりと確認できます」という回答は受け入れられません。PPA を追加するとき (何年も追加していません)、キーボードの「Enter」というキーを押すと、新しいエントリの前に空の行を追加できます (説明コメントを追加することもできますが、私は技術ライターなので...)。私はsources.confすっきりと整然としたものが好きです。

/etc/apt/sources.d

つまり、解析するファイルは 1 つだけではなく 6 つあることになります。

私の知る限り、構成ファイルが 1 つある場合と 6 つある場合とで「絶対に」利点はありません (議論のために、構成ファイルが 3 つある場合も 2 つある場合もありますが、それは問題ではありません... 1 つある方が 2 つより優れています)。

誰か合理的な利点を考え出してください。「カスタム追加がはっきりと見える」というのは貧乏人の言い訳です。

付け加えておきますが、私は変化が大好きです。ただし、変化によってメリットがもたらされる場合のみです。

最初の応答後に編集:

これにより、独自のリポジトリを必要とする新規インストールでは、重複するエントリが追加されていないことを確認するためにフラット ファイルを検索する必要がなくなります。

今では、フラット ファイルではなくディレクトリで重複を検索する必要があります。管理者が変更を加えないと仮定しない限り...

これにより、システム管理者は、モノリシック ファイルを編集することなく、リポジトリ セットを簡単に無効化 (名前変更) または削除 (削除) できるようになります。

管理者は、名前を変更する適切なファイルを見つけるためにディレクトリを grep する必要があります。以前は、1 つのファイルを検索して 1 行をコメント アウトしていました。これは、「ほぼ」すべての管理者にとって sed ワンライナーです。

これにより、パッケージのメンテナーは、関連のないリポジトリの構成を誤って変更してしまうことを心配することなく、リポジトリの場所を更新するための簡単なコマンドを発行できるようになります。

これは理解できません。パッケージのメンテナーはリポジトリの URL を知っていると「想定」しています。この場合も、sed単一のファイルではなくディレクトリが必要です。

答え1

各リポジトリ (またはリポジトリのコレクション) を独自のファイルに格納すると、手動でもプログラムでも管理が簡単になります。

  • これにより、独自のリポジトリを必要とする新規インストールでは、重複するエントリが追加されていないことを確認するためにフラット ファイルを検索する必要がなくなります。
  • これにより、システム管理者は、モノリシック ファイルを編集することなく、リポジトリ セットを簡単に無効化 (名前変更) または削除 (削除) できるようになります。
  • これにより、パッケージのメンテナーは、関連のないリポジトリの構成を誤って変更してしまうことを心配することなく、リポジトリの場所を更新するための簡単なコマンドを発行できるようになります。

答え2

技術的なレベルでは、いくつかの大規模で人気のあるシステム情報ツールでこれらの変更を処理しなければならなかった者として、基本的には次のようになります。

ソースリストd/

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

リポジトリの行をコメント アウトした場合、以下と同じチェックも実行しない限り、これらのテストは間違っていることに注意してください。以下と同じチェックを実行している場合は、1 つのファイルではなく多数のファイルに対して実行される点を除けば、まったく同じ複雑さになります。また、すべての可能性のあるファイルをチェックしていない限り、重複する項目が追加される可能性があり、実際に追加されることがよくあるため、そのうちの 1 つを削除するまで apt がエラーを出します。

ソースリスト

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

Google Chrome の開発者は、Google Chrome ソースの存在を確認せず、Chrome パッケージが作成する正確なファイル名を頼りにしていました。それ以外の場合は、sources.list.d に、希望どおりの名前の新しいファイルを作成します。

どのようなソースを持っているかを確認するには、もちろん、次のようにすると読みやすく、保守も容易になるため、あまり見栄えがよくありません。

cat /etc/sources.list

したがって、これは基本的に自動更新を目的としており、私が知る限り、ユーザーに提供できる簡単な単一コマンドを提供する目的で行われました。ユーザーにとっては、リポジトリが追加されているかどうかを確認するために 1 つのファイルではなく多くのファイルを読み取る必要があることを意味し、apt にとっても、1 つのファイルではなく多くのファイルを読み取る必要があることを意味します。

現実世界でこれをうまく行うには、名前に関係なくすべてのファイルに対するチェックをサポートし、実行するアクションが必須かどうかをテストする必要があります。

ただし、うまくやらないと、アイテムがソースのどこかにあるかどうかのチェックを無視して、ファイル名だけをチェックすることになります。ほとんどの自動化されたものはそうしていると思いますが、結局、すべてをリストして、それらのファイルの 1 つが一致するかどうかに基づいて動作できるようにする必要があるだけなので、実際の結果は、はるかに複雑になることだけでした。

一括編集

多くのサーバーを実行していることを考えると、/etc/apt/sources.list.d/ をループして、まず項目がすでにsources.listに含まれていないかどうかを確認し、含まれていない場合はその項目をsources.listに追加し、sources.list.dファイルを削除し、すでにsources.listに含まれている場合はsources.list.dファイルを削除するという夜間ジョブのスクリプトを作成したいと思うでしょう。

シンプルさとメンテナンスのしやすさ以外に、sources.list のみを使用することにデメリットはないので、特にシステム管理者による創造的でランダムなアクションを考慮すると、そのようなものを追加することは悪い考えではないかもしれません。

上記のコメントで述べたように、inxi -r はアクティブなリポジトリをファイルごとにきれいに出力しますが、もちろん編集や変更は行いません。したがって、これは解決策の半分にすぎません。ディストリビューションが多数ある場合、それぞれの方法を学ぶのは確かに面倒です。また、残念ながら、ランダム性は例外ではなく、確かにルールです。

答え3

サーバーを手動で管理している場合、状況がさらに混乱することに同意します。ただし、プログラムによる管理 (つまり、「コードとしての構成」) にはメリットがあります。Puppet、Ansible、Chef などの構成管理ソフトウェアを使用する場合、ファイルを解析して特定の行を追加または削除するのではなくapt update、ディレクトリ内のファイルをドロップまたは削除して を実行する方が簡単です。

/etc/apt/sources.list特に、これにより、サードパーティによって作成された複数の独立したモジュールから、単一の「ファイル」リソース (例: ) の内容を管理する必要がなくなります。

この理由から、私は Ubuntu が sudoers.d、rsyslog.d、sysctl.d、cron.d、logrotate.d などの「.d」ディレクトリを幅広く使用していることを高く評価しています。

答え4

これにより、パッケージはスクリプトに頼ることなく追加のソースを追加できるようになります。

たとえば、Microsoft の Skype パッケージをインストールすると、skype.com のソースが自動的に構成され、更新プログラムをダウンロードします。システムから Skype パッケージを削除すると、このパッケージ ソースも再度無効になります。

フラット ファイルで同じ効果を得たい場合は、Skype のインストール スクリプトで source.list を変更する必要があり、多くのシステム管理者が少し不安を感じる可能性があります。

関連情報