各リポジトリ (またはリポジトリのコレクション) を独自のファイルに格納すると、手動でもプログラムでも管理が簡単になります。
- 独自のリポジトリを必要とする新しいインストールでは、重複するエントリが追加されていないことを確認するためにフラット ファイルを検索する必要がなくなります。
- システム管理者は、モノリシックなファイルを編集しなくても、リポジトリ セットを簡単に無効化 (名前変更) または削除 (削除) できます。
- パッケージ管理者は、関連のないリポジトリの構成を誤って変更してしまう心配をすることなく、簡単なコマンドでリポジトリの場所を更新できます。
技術的なレベルでは、いくつかの大規模で人気のあるシステム情報ツールでこれらの変更を処理しなければならなかった人として、基本的には次のようになります。
sources.list.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 つではなく多くのファイルに対して実行されることを除いて、まったく同じ複雑さです。また、可能性のあるすべてのファイルをチェックしていない限り、重複したアイテムを追加する可能性があり、多くの場合、それらのいずれかを削除するまで apt が文句を言います。
sources.list の場合
# 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 開発者は、Chrome パッケージが作成する正確なファイル名に依存して、Google 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 はアクティブなリポジトリをファイルごとにきれいに出力しますが、もちろんそれらを編集または変更しないため、解決策の半分に過ぎません。それが多くのディストリビューションである場合、それぞれがどのようにそれを行うかを学ぶのは苦痛です.
サーバーを手動で管理している場合は、事態がさらに混乱することに同意します。ただし、プログラムによる管理 (つまり、「コードとしての構成」) にはメリットがあります。 Puppet、Ansible、Chef などの構成管理ソフトウェアを使用する場合は、ディレクトリにファイルをドロップまたは削除して apt update を実行する方が簡単です。 、ファイルを解析して特定の行を追加または削除する代わりに。
特に、単一の「ファイル」リソースのコンテンツを管理する必要がなくなるためです。例:/etc/apt/sources.list 、サードパーティによって作成された複数の独立したモジュールから。
この特定の理由から、Ubuntu が ".d" ディレクトリを広く使用していることに感謝しています。つまり、sudoers.d、rsyslog.d、sysctl.d.、cron.d、logrotate.d などです。