web-dev-qa-db-ja.com

/etc/apt/sources.listよりも/etc/apt/sources.list.dの利点は何ですか

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

/etc/apt/sources.d

解析するファイルが1つではなく6つあることを意味します。

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

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

私は変更を追加する必要がありますが、変更によってもたらされる利点がある場合のみです。

最初の応答後に編集：

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

今、彼らはフラットファイルの代わりにだましのディレクトリを検索しなければなりません。彼らが管理者が物事を変更しないと仮定しない限り...

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

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

これにより、パッケージの保守担当者は、無関係なリポジトリの構成を誤って変更することを心配する必要なく、リポジトリの場所を更新する簡単なコマンドを提供できます。

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

linuxaptetc
14
thecarpy

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

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

以下と同じチェックを行わない限り、repo行をコメント化した場合、これらのテストは間違っていることに注意してください。彼らが以下と同じチェックを行っている場合は、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開発者は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はアクティブなリポジトリをファイルごとにきちんと出力しますが、もちろんそれらを編集または変更することはないため、ソリューションの半分になります。それが多くのディストリビューションである場合、それはそれぞれがどのようにそれを行うかを学ぶことの苦痛であり、それは確かです、そしてランダムさは確かに例外ではなく悲しいルールです。

14
Lizardx

独自のファイルに各リポジトリ（またはリポジトリのコレクション）を含めると、手動でもプログラムでも簡単に管理できます。

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

サーバーを手動で管理している場合は、混乱が生じることに同意します。ただし、プログラムによる管理（「コードとしての構成」）にはメリットがあります。 Puppet、Ansible、Chefなどの設定管理ソフトウェアを使用する場合、ファイルを解析して特定の行を追加または削除する代わりに、dirにファイルをドロップまたは削除してapt updateを実行する方が簡単です。

特に、サードパーティによって作成された複数の独立したモジュールから、単一の「ファイル」リソース（例：/etc/apt/sources.list）のコンテンツを管理する必要がなくなるためです。

この特定の理由、つまりsudoers.d、rsyslog.d、sysctl.d。、cron.d、logrotate.dなどの理由から、Ubuntuが「.d」dirsを幅広く使用していることに感謝します。

10
Martijn Heemels

nemo がコメントで指摘されているように、ディレクトリの主な利点の1つは、「所有権」の概念を可能にすることです。

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

現在受け入れられている答え は、Google Chromeインストーラーは、予想した場所にのみエントリを作成または削除する必要があると想定しているが、何かを自動化していることを悪いことと見なしています。それ以外の場合は、あらゆる種類の恐ろしいEdgeケースが発生します。次に例を示します。

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

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

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

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

5
IMSoP

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

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

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

3
Simon Richter