この質問は以前に要求されていることを知っていますが、「カスタム追加が明確に表示されます」という答えを受け入れません。 ppaを追加するとき（何年もこれを行っていない）、キーボードで「Enter」と表示されたキーを押すと、新しい項目の前に空白行を追加できます（説明コメントも追加します）。でも私は技術作家だから…。私は私のsources.conf清潔さが好きです。
/etc/apt/sources.d
つまり、解析するファイルが1つではなく6つあることを意味します。
AFAIK、6つよりも1つのプロファイルを持つことには「絶対に」利点はありません（議論のために3つまたは2つがあるかもしれませんが、関係ありません... 1はまだ2よりも優れています）。
誰が正当な利点を考えることができるのか、「カスタム追加が確実に見える」というのは貧しい人の言い訳だ。
私は変更が好きですが、それが利益をもたらすときにのみ可能であることを付け加える必要があります。
最初の回答後の修正：
重複エントリを追加しないように、フラットファイルを検索する必要がない独自のリポジトリを必要とする新しいインストールを許可します。
今、彼らはフラットファイルの代わりにディレクトリから重複する項目を検索する必要があります。管理者が状況を変えないと思わない限り...
これにより、システム管理者はファイル全体を編集しなくても、ストレージセットを簡単に無効にする（名前を変更）または削除（削除）できます。
管理者は、名前を変更する適切なファイルを見つけるためにディレクトリをgrepする必要があります。そうする前にファイルを検索し、「ほぼ」すべての管理者のsed行に対応する行をコメントアウトします。
これにより、パッケージマネージャは、関係のないストレージの構成を誤って変更することを心配することなく、ストレージの場所を更新する簡単なコマンドを提供できます。
私はこれを理解しておらず、パッケージマネージャは自分のリポジトリのURLを知っていると「家庭」です。繰り返しますが、sed単一のファイルではなくディレクトリにする必要があります。
答え1
各リポジトリ（またはリポジトリコレクション）を独自のファイルに配置することで、手動でプログラム的に簡単に管理できます。
- 重複エントリを追加しないように、フラットファイルを検索する必要がない独自のリポジトリを必要とする新しいインストールを許可します。
- これにより、システム管理者はファイル全体を編集しなくても、ストレージセットを簡単に無効にする（名前を変更）または削除（削除）できます。
- これにより、パッケージマネージャは、関係のないストレージの構成を誤って変更することを心配することなく、ストレージの場所を更新する簡単なコマンドを提供できます。
答え2
技術的な観点からは、いくつかの大規模で人気のあるシステム情報ツールでこれらの変更を処理する必要がある人として、基本的に次のようにまとめられています。
source.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つではなく複数のファイルに対して実行されることを除いて、複雑さは同じです。また、すべての可能なファイルを確認しないと、重複する項目を追加することができ、しばしばそうするので、その項目の1つを削除するまで苦情を提起するのは簡単です。
ソースリストの場合
# 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パッケージで生成された正確なファイル名を使用して表示します。他のすべての場合は、resources.list.dに新しいファイルを作成し、必要に応じて名前を付けます。
もちろん、以下より読みやすくメンテナンスしやすい方法がないので、どのリソースがあるかを確認するのはあまり良くありません。
cat /etc/sources.list
私が知っている限り、これは基本的に更新を自動化し、ユーザーに簡単な単一のコマンドを提供することです。これは、ユーザーがリポジトリが追加されたことを確認するために1つのファイルではなく多くのファイルを読み取る必要があり、aptの場合は1つのファイルではなく多くのファイルを読み取る必要があることを意味します。
現実の世界でこれをうまく行うには、名前が何であれ、すべてのファイルスキャンをサポートし、必要なタスクを実行する必要があるかどうかをテストする必要があるからです。
ただし、うまくいかない場合は、項目がソースのどこかにあるかどうかを確認するのを無視して、ファイル名だけを確認してください。私はそれがほとんどの自動化されたタスクだと思いますが、最終的にはすべてをチェックしてリストし、それらのファイルのいずれかが一致するかどうかに応じてアクションを取ることができるので、唯一の実際の結果はファイルをより複雑にすることです。 。
一括編集
多くのサーバーを実行することを考えると、/etc/apt/sources.list.d/を繰り返す夜間ジョブを作成し、最初にエントリがresources.listにないことを確認し、そうでない場合はsource.listにエントリを追加し、source .list.dファイルを削除し、すでにsource.listにある場合はsource.list.dファイルを削除します。
単純さとメンテナンスの容易さに加えて、resources.listを使用することには欠点がないので、同様のものを追加することは悪い考えではないかもしれません。特に、システム管理者の創造的なランダム性を考えると、さらにそうです。
上記の説明で述べたように、inxi -rは各ファイルのアクティブリポジトリをきちんと印刷しますが、もちろん編集も変更もしないので、これはソリューションの半分にすぎません。分布が多い場合は、各分布がどのような役割を果たしているのかを学ぶのが痛いです。これは確かにそうです。残念ながら、ランダム性は確かに例外ではないルールです。
答え3
サーバーを手動で管理すると、状況がより混乱することに同意します。ただし、これはプログラムによる管理（「コードで構成」など）を容易にします。 Puppet、Ansible、Chefなどの構成管理ソフトウェアを使用する場合は、ファイルを解析して特定の行を追加または削除するapt updateよりも、ディレクトリ内のファイルを削除または実行する方が簡単です。
/etc/apt/sources.list特に、これは、サードパーティが作成した複数の独立したモジュールで単一の「ファイル」リソースの内容を管理する必要がないためです。
この特別な理由から、私はUbuntuで ".d"ディレクトリ（ sudoers.d、rsyslog.d、sysctl.d.、cron.d、logrotate.dなど）を広く使用していただきありがとうございます。
答え4
これにより、パッケージはスクリプトを使用せずに追加のソースを追加できます。
たとえば、MicrosoftのSkypeパッケージをインストールすると、skype.comフィードはアップデートをダウンロードするように自動的に設定されます。システムからSkypeパッケージを削除すると、このパッケージフィードも再び無効になります。
フラットファイルを使用して同じ効果を得るには、Skypeのインストールスクリプトでsource.listを変更する必要があります。これにより、多くのシステム管理者が少し不安になる可能性があります。