プログラミング

Pkgsrc Is Cool (2022)

Pkgsrc Is Cool (2022) (wisellama.rocks)

13 pointsby Tomte2026年9月14日3 コメント

要約

PkgsrcはNetBSDのパッケージマネージャーですが、LinuxやmacOSなど他のUnix系OSでも利用可能です。ソースコードからのビルドをサポートし、ベースシステムとインストールされたパッケージを分離する仕組みが特徴です。これにより、システムフォルダを汚染することなく、ユーザーごとに独立した環境を構築できます。

全文翻訳

pkgsrc Is Cool

公開日: 2021-12-23 22:17:43 -0800 PST

最終更新日: 2022-04-24 21:06:24 -0700 PDT

数ヶ月前、Mastodonのフィードでpkgsrcについて偶然見かけたのを覚えています。それ以前は全く知りませんでした。そして今…まさに今、私はpkgsrcを使ってソースからビルドしたEmacsのバージョンでこれらの文章を書いています。

PkgsrcはNetBSDのパッケージマネージャーですが、NetBSDのポータビリティ哲学のおかげで、Linux、Mac、Solarisといった他のUnix系オペレーティングシステムでもパッケージマネージャーとして完全にサポートされています。バイナリパッケージのインストールもサポートしていますが、私が興味を持った理由は、pkgsrcがソースからのパッケージビルドもサポートしている点です。

他の類似プロジェクトの文脈として、pkgsrcは数十年前からFreeBSDのPortsコレクションからフォークされたものです。そのため、他のBSDに慣れている人にとっては、これは他のプラットフォームで動作するportsコレクションのようなものです。さらに良いことに、pkgsrcとNetBSDは用語を正しく使い、「port」をCPUアーキテクチャサポートの用語として残し、これらを「packages」と正しく呼んでいます。その他、似たようなプロジェクトにはMacPorts、Gentooのemerge、GNU Guix、Ravenportsなどがあります。おそらくいくつか見落としているかもしれませんが、要点は伝わるでしょう。興味があれば、他にも多くの選択肢があります。それらを比較対照するつもりはありません。正直、私が10年前に使ったことのある唯一の類似プロジェクトはMacPortsで、その時は何も分かっていませんでした。

なぜ使ったのか？

プログラムを実行するために新しいパッケージをインストールする必要があるのがずっと嫌でした。主な理由は、新しいパッケージが他のパッケージを引き込み、それらがすべて /bin や /lib のようなシステムフォルダを余分なもので汚染する可能性があるからです。試していたプログラムを削除するたびに、結局そのプログラムは不要になるのですが、ベースシステムには余分なものが残ってしまいます。これまでにインストールしてきた「ベースシステム」とそれ以外の「ゴミ」を分離する方法があるとは、あまり考えたこともありませんでした。

しかし、これはまさにNetBSDが行っていることです。NetBSDの /bin などに対するベースシステムは、ソースコードリポジトリからビルドできるような、本当にNetBSDのコアシステムコードのためだけです。それ以外のものは別の場所にインストールされるべきです。デフォルトでは、pkgsrcは /usr/pkg にものをインストールし、そこで /usr/pkg/bin や /usr/pkg/lib などの独自のサブディレクトリツリーを作成します。このように、その特定の pkg ディレクトリは、ベースオペレーティングシステムから分離された自己完結型のユーザランドのようになります。私は実際にはNetBSD自体ではなくDebian上でpkgsrcを使用していますが、動作は同じです。

さらに良いことに、pkgsrcは特権なしモードで使用でき、ユーザーのホームディレクトリに ~/pkg のようにローカルにものをインストールできます。これにより、ユーザーは他のユーザーから分離された独自のカスタムユーザランドを持つことができます。ユースケースによってはこれが望ましいことではないかもしれませんが、ユーザー専用の完全に分離されたシステムをほとんど実行できることが特にクールだと感じました。パッケージをインストールするために sudo/doas を必要としたくなかったので、私は実際には特権なしモードで ~/pkg をベースディレクトリとしてpkgsrcを使用しています。

したがって、これはこの質問に対する長い説明でした。なぜpkgsrcを使い始めたのか？ローカルのホームディレクトリにパッケージをインストールでき、それらのパッケージをソースからビルドでき、そしてこのシステムが私が遭遇するであろうどのオペレーティングシステムでも動作することを知っているからです（そして、比較的若いながらもいくつかの奇妙なものを使ってきました）。

仕組み

Pkgsrc自体はパッケージリポジトリではありません。それは単に、各パッケージをビルドする方法と、パッケージに必要な依存関係を定義するMakefilesのコレクションです。各パッケージのMakefileは、パッケージのソースコードをどこからダウンロードするか、必要なパッチをどのように適用するか、そしてどのようにビルドするかを定義します。これは私にとって長年の疑問を解決しました。なぜGitHubの「リリース」はソースコードのtarball/zipスナップショットをビルドするのか？さて、pkgsrcのようなシステムは、そのtarballを使用して、完全なリポジトリをクローンする必要なく（あるいはソース管理ソフトウェアをインストールする必要すらなく）、特定のバージョンのソースコードをダウンロードします。

Pkgsrcは、GitHubやSourceforge（あるいはプロジェクトのソースコードがホストされている他の場所）のような様々なウェブサイトにアクセスし、ビルドするパッケージの指定されたバージョンをダウンロードします。これは、pkgsrcが単一のリポジトリサーバーに依存せず、各プロジェクト自身のサーバーに依存するため、非常に分散化されています。（余談ですが、これはGoプログラミング言語が依存関係を処理する方法に似ています）。これにより、単一のプロジェクトのウェブサイトがダウンした場合にそのソフトウェアをビルドできないという潜在的な問題が発生する可能性があります。しかし、Makefilesはソースコードをダウンロードするための代替のdistfileミラーも指定しています。ここで私にとって新しい専門用語は「distfile」で、これはパッケージの特定のバージョンのソースコードtarballスナップショットのことです。

Tinfoil Hat Time

私の「非合理的」かもしれない要件の1つは、インターネットがいつかダウンした場合に、自分のネットワークからソフトウェアをインストールできるようにしたいということでした。単に私のインターネットだけでなく、THEインターネット全体です。そして、インターネット全体がダウンすることはまずないだろうと思いますが、政府の検閲によってインターネットが完全に異なるサイロに断片化されるポイントに達する可能性はあると思います。

より実用的な方法としては、複数のコンピュータを更新する際に帯域幅を節約するために、ローカルネットワークからソフトウェアをインストールできるようにしたいとも思いました。だからこそ、私は自分のサーバーでいくつかのミラーをホストしています（私のミラー）。

それらのミラーの1つがpkgsrc distfileミラーです。私は MASTER_SITE_OVERRIDE オプションを使用してpkgsrcを自分のdistfileミラーを使用するように指示できました。これにより、distfileミラーがすでにすべてのプロジェクトのソースコードにアクセスしてダウンロードしている（あるいは、私がすでにそれを行ったミラーからミラーリングしている）ため、オフラインでサポートされているすべてのpkgsrcパッケージをビルドできます。

これは奇妙な、ほとんど「プレッパー」的な終末論的な考え方であることは認識していますが、自分のネットワーク上でローカルにソフトウェアをインストールできるようにしたいと本当に思っていました。pkgsrcは、私が発見できるあらゆるオペレーティングシステム、あらゆるCPUアーキテクチャ向けのソフトウェアをソースからビルドし、すべてを自分のサーバーから実行できるようにするソリューションを提供してくれました。

その他の記事

pkgsrcに関する追加情報を検索した結果、以下のクールなリンクが見つかりました。

フォローアップ

これを巨大な記事にしないために、この記事ではpkgsrcがクールだと思う理由と、なぜ私がそれを使いたかったのかを単純に説明します。どのように使用しているかについては、別の記事でフォローアップします。

また、Clangをデフォルトのpkgsrcコンパイラとして使用することについても、別の記事を書くべきでしょう。私はそれを機能させるためにかなりの時間を費やしました。それに関するドキュメントは少し散らばっていて誤解を招くものでした。

結局、pkgsrcに関する追加の記事を書きました！

Git - Fediverse