/etc/apt/sources.listに対する/etc/apt/sources.list.dの利点は何ですか

この質問は以前に聞かれたことがあることは知っていますが、「カスタムの追加がはっきりと見える」という答えは受け入れません。私がppaを追加するとき（私は何年もやっていない）、キーボードの「Enter」というラベルのキーを押すと、新しいエントリの前に空の行を追加できます（説明コメントも追加しますが、私はテックライターなので、....）。私はsources.confきれいできれいです。

/etc/apt/sources.d

つまり、解析するファイルは1つではなく半ダースです。

私の知る限り、「絶対に」6つの構成ファイルに対して1つの構成ファイルを使用することには利点がありません（議論のために、おそらく3でも2でも構いません... 1はまだ2に勝っています）。

誰かが合理的な優位性を考え出すことができますか、「カスタムの追加をはっきりと見ることができる」というのは貧しい人の言い訳です。

私は変更を追加する必要がありますが、変更によってもたらされるメリットがある場合にのみ、変更が大好きです。

最初の応答後に編集：

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

今、彼らはフラットファイルの代わりにデュープのディレクトリを検索する必要があります。管理者が物事を変えないと仮定しない限り...

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

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

パッケージメンテナーは、無関係なリポジトリの設定を誤って変更することを心配することなく、リポジトリの場所を更新する簡単なコマンドを提供できます。

私はこれを理解していません、私はパッケージメンテナーが彼のリポジトリのURLを知っていると仮定します。繰り返しsedますが、単一のファイルではなくディレクトリが必要です。

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

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つではなく多くのファイルに対して実行されることを除いて、まったく同じ複雑さです。また、可能性のあるすべてのファイルをチェックしていない限り、重複アイテムを追加できます。重複アイテムを追加すると、そのうちの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などです。

NEMOはコメントで指摘し、ディレクトリの主要な利点の一つは、それが「所有」の概念を可能にしています。

最新のLinuxディストリビューションとインストーラーはすべて、パッケージの概念に基づいています。これは、可能な限り原子的に追加および削除できる独立したソフトウェアです。dpkg（したがってapt）パッケージをインストールするたびに、システム上のどのファイルがそのインストーラーによって作成されたかを追跡します。パッケージのアンインストールは、主にこれらのファイルの削除で構成されます。

現在受け入れ答えは、 Google Chromeのインストーラは、それだけで、それは期待の場所にエントリを作成または削除すべきであると仮定していることは悪いこととして、それがかかりますが、恐ろしいエッジケースのすべての種類には何も他のリードを自動化します。例えば：

• sources.listインストール時に行が存在するが、コメントアウトされている場合、インストーラーはコメントを解除するか、重複を追加する必要がありますか？
• アンインストーラーが行を削除しても、ユーザーがその横にコメントを追加または編集した場合、ファイルにはコメントが壊れたままになります。
• ユーザーが手動で行を追加した場合、インストーラーは追加しないことを知ることができます。しかし、アンインストーラーはそれを削除しないことをどのように知っていますか？

所有権のために個別のファイルは必要ありません。たとえば、インストーラーは、特定の行セットを「所有」していることを示すコメントブロックを含めることができます。その場合、同じリポジトリの他の言及ではなく、常にその正確なブロックをファイルで検索します。

他のすべてが同じであれば、単一の構成ファイルに対する編集の自動化は、個別のファイルの作成と削除の自動化よりも常に複雑になります。少なくとも、行を削除するには、などのパターンマッチングツールを使用する必要がありますsed。より複雑なファイルでは、行の追加と削除の両方に、適切なセクションへの追加、または周囲の書式を損なうことなく削除するために、ファイル形式の知識を持つスクリプトツールが必要になる場合があります。

とにかく、インストーラーは手動で編集された構成をいじるのを避ける必要があるため、自動化されたツール所有の構成を、自動化ツールが管理しやすい形式にすることは理にかなっています。

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

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

フラットファイルで同じ効果を得るには、Skypeのインストールスクリプトでsources.listを変更する必要があります。これは、多くのシステム管理者が少し不安を感じるかもしれません。

おしゃれであるように見える以外に、正当な理由があるとは思いません。私にとっては、ディレクトリはリーフまたはノードのいずれかでなければならないというルールを破っています。つまり、ファイルまたはディレクトリのみを含み、両方を混在させることはできません。

ファイルが小さくなり、読みやすくなると思います-非常に長くなる可能性があるsudoルールの場合、あるタイプのユーザー（開発者など） ）、およびこのマシンでdevにsudoを許可する必要がある場合は、これらをconfigディレクトリに追加します。したがって、必要なファイルの数を少なくする必要があります-考えられるあらゆる組み合わせではなく、開発者、管理者、sysopなどのファイルだけです。

そこで、私は自分自身に矛盾しました。