ソフトウェアリポジトリ(略してリポジトリ)とは、ソフトウェアパッケージを保存する場所です。多くの場合、目次とメタデータも保存されます。ソフトウェアリポジトリは通常、ソース管理、バージョン管理、またはリポジトリマネージャによって管理されます。パッケージマネージャを使用すると、リポジトリ(「パッケージ」と呼ばれることもあります)を自動的にインストールおよび更新できます。
多くのソフトウェアパブリッシャーやその他の組織は、この目的のためにインターネット上にサーバーを保有しており、無料または有料で提供しています。リポジトリは、Perlプログラミング言語のCPANのように特定のプログラム専用のものもあれば、オペレーティングシステム全体のものもあります。このようなリポジトリの運営者は通常、パッケージ管理システム、つまりリポジトリからソフトウェアパッケージを検索、インストール、その他の操作を行うためのツールを提供しています。たとえば、多くのLinux ディストリビューションは、 Debianベースのディストリビューションでよく見られるAdvanced Packaging Tool (APT)や、 Red Hatベースのディストリビューションで見られるYellowdog Updater, Modified ( yum ) を使用しています。また、 Arch Linuxで使用されている pacman やSabayon Linuxで使用されている equoなど、複数の独立したパッケージ管理システムも存在します。

ソフトウェアリポジトリは有用なパッケージを含むように設計されているため、主要なリポジトリはマルウェアを含まないように設計されています。コンピュータが信頼できるベンダーのデジタル署名付きリポジトリを使用するように構成され、適切なアクセス許可システムと組み合わせられている場合、これらのシステムに対するマルウェアの脅威は大幅に減少します。副次的な効果として、これらの機能を備えた多くのシステムは、ウイルス対策ソフトウェアなどのマルウェア対策ソフトウェアを必要としません。[ 1 ]
主要なLinuxディストリビューションのほとんどは、メインリポジトリをミラーリングする多数のリポジトリを世界中に持っています。
クライアント側では、パッケージマネージャーがリポジトリからのインストールや更新を支援します。
パッケージ管理システムは、パッケージ開発プロセスとは異なります。
パッケージ管理システムの典型的な用途は、異なるソースからのコードを統合して、一貫性のあるスタンドアロンのオペレーティングユニットを作成することです。したがって、パッケージ管理システムは、Linuxディストリビューション、場合によっては特定の制限されたアプリケーション向けにカスタマイズされたディストリビューションを作成するために使用される可能性があります。
一方、パッケージ開発プロセスは、共通のテーマを持つ一連の関数やルーチンのコードとドキュメントの共同開発を管理するために用いられ、それによって通常は単体では完全で使用可能なものではないソフトウェア機能のパッケージが生成されます。優れたパッケージ開発プロセスは、ユーザーが適切なドキュメント作成とコーディングの慣習に従うことを支援し、一定レベルの単体テストを統合します。
以下の表は、コントリビュートソフトウェアのリポジトリを持ついくつかのプログラミング言語を示しています。「自動チェック」列には、実行されるルーチンチェックの内容が記載されています。
複数のオペレーティングシステム上で、異なるバージョンのコアコードや、使用する可能性のある他のコントリビュートパッケージを用いてソフトウェアをテストできる人はごくわずかです。Rプログラミング言語の場合、包括的Rアーカイブネットワーク(CRAN)が定期的にテストを実行しています。
これがどのように価値があるかを理解するために、2人の開発者、サリーとジョンがいる状況を想像してみましょう。サリーはパッケージAを提供します。サリーは、Microsoft Windowsの1つのバージョンでのみ現在のバージョンのソフトウェアを実行し、その環境でのみテストを行いました。CRANは、ほぼ定期的に、12種類のオペレーティングシステムとコアR言語ソフトウェアのバージョンの組み合わせで、サリーの提供したパッケージをテストします。いずれかの組み合わせでエラーが発生した場合、サリーはそのエラーメッセージを受け取ります。運が良ければ、そのエラーメッセージの詳細から、サリーが現在のハードウェアとソフトウェアでエラーを再現できなくても、エラーを修正するための十分な情報が得られる可能性があります。次に、ジョンがパッケージAを使用するパッケージBをリポジトリに提供したとします。パッケージBはすべてのテストに合格し、ユーザーに提供されます。その後、サリーがAの改良版を提出すると、Bが壊れてしまいます。自動チェックにより、ジョンに情報が提供され、ジョンは問題を修正できます。
この例は、Rのコントリビュートパッケージシステムの長所と短所の両方を示しています。CRANはコントリビュートパッケージの自動テストをサポートしていますが、CRANにコントリビュートされるパッケージは、使用する他のコントリビュートパッケージのバージョンを指定する必要はありません。パッケージの特定バージョンを要求する手順は存在しますが、コントリビューターがそれらの手順を使用しない場合もあります。
さらに、CRANのようなリポジトリは、提供されたパッケージを定期的にチェックすることで、コア言語の開発バージョンに対して、広範かつアドホックなテストスイートを提供します。上記の例でサリーが理解できない、あるいは不適切だと思うエラーメッセージ(特に開発バージョンの言語からのもの)を受け取った場合、彼女は(Rの場合によくあるように)言語のコア開発チームに助けを求めることができます。このようにして、リポジトリはコア言語ソフトウェアの品質向上に貢献できるのです。
(この表の一部は、 Stack Overflowの「プログラミング言語別トップリポジトリ一覧」[ 20 ]からコピーしたものです。)
範囲が限定されている注目すべきリポジトリには、以下のようなものがあります。
パッケージマネージャは、リポジトリとその配布を管理するのに役立ちます。リポジトリが更新されると、パッケージマネージャは通常、ユーザーがマネージャを介してそのリポジトリを更新できるようにします。また、他のリポジトリ間の依存関係などの管理にも役立ちます。マネージャの例としては、次のようなものがあります。
企業環境では、ソフトウェアリポジトリは通常、アーティファクトを保存したり、セキュリティ制限のためにアクセスできない外部リポジトリをミラーリングしたりするために使用されます。このようなリポジトリは、アクセス制御、バージョン管理、アップロードされたソフトウェアのセキュリティチェック、クラスタ機能などの追加機能を提供することができ、通常は1つのパッケージでさまざまな形式をサポートして、企業内のすべてのニーズに対応し、単一の真実のポイントを提供することを目指しています。1つの例として、Sonatype Nexus Repositoryがあります。[ 29 ]
サーバー側では、ソフトウェアリポジトリは通常、ソースコード管理システムまたはリポジトリマネージャによって管理されます。リポジトリマネージャの中には、複数のリポジトリの場所を1つのURLに集約し、キャッシュプロキシを提供するものもあります。継続的ビルドを行うと、多くの成果物が生成され、多くの場合、中央で保存されるため、リリースされない成果物を自動的に削除することが重要です。
開発ライフサイクルの一環として、ソースコードは継続的インテグレーションを使用してバイナリ成果物に継続的にビルドされます。これは、開発者がリポジトリから成果物を取得してビルドをプッシュするのと同様に、バイナリリポジトリマネージャと連携します。CIサーバーとの緊密な統合により、次のような重要なメタデータを保存できます。
アーティファクトとパッケージは本質的に異なる意味を持ちます。アーティファクトは単にファイルの出力またはコレクション(例:JAR、WAR、DLL、RPMなど)であり、それらのファイルの1つにメタデータ(例:POMファイル)が含まれる場合があります。一方、パッケージは、パッケージの種類に適したファイル(例:DLL、PDB)を含む、明確に定義された形式(例: NuGet )の単一のアーカイブファイルです。 [ 30 ]ビルドから多くのアーティファクトが生成されますが、他のタイプも重要です。パッケージは基本的に、ライブラリまたはアプリケーションの2つのいずれかです。[ 31 ]
ソースファイルと比較すると、バイナリ成果物は桁違いに大きいことが多く、削除または上書きされることはまれであり(スナップショットやナイトリービルドなどのまれなケースを除く)、通常はID、パッケージ名、バージョン、ライセンスなどの多くのメタデータが付随しています。
メタデータはバイナリ成果物を記述するものであり、成果物自体とは別に保存および指定され、いくつかの追加的な用途があります。次の表は、一般的なメタデータの種類とその用途を示しています。