いままでRustのパッケージはすべてGuixのパッケージと一対一対応していた。そのため、あるRustパッケージをビルドするためには、 #:cargo-inputs として引数に渡されている依存パッケージをすべてビルドする必要があった(たしかビルドしないというオプションはあったはずだが)。一方Rustのビルドプロセス上、すべての依存はソースコードを利用してコンパイルされるため、依存パッケージがバイナリへビルドされている必要は全くなかった。また、Rustパッケージに対応するGuixパッケージの数も依存の数に応じてどんどん増えていってしまうなど、管理上の問題も多数あった。 ...
更新履歴 2023-06-09: チャンネルの依存のintroduction節の書き方の変更 序文 前回の記事では、ビルドを伴うパッケージの作成を行いました。しかし、どうしてもビルドがうまくいかないこともあります。特に前回触れたインポーターがまだない他の既存パッケージマネージャで管理されたソフトウェアや、そもそもインポーターが介在する余地のないような独自のビルド手順を持つソフトウェアなどで、まだGNU Guixの公式チャンネルに実装されていない依存が大量にある場合には、多大な労力が必要になります。さらに言うと、我々が利用しているソフトウェアはソースが公開されているとは限りません。そのようなプロプライエタリなソフトウェアをソースコードからビルドすることは当然不可能です。このような場合、GNU Guixでソフトウェアの管理を行うことは不可能なのでしょうか。 ...
序文 前回の記事では、フォントのパッケージ定義を通じて、パッケージ定義の流れを解説しました。この記事では一歩進んで、ビルドを伴うパッケージの定義を行っていきます。 実はGNU Guixはその思想上、この「ビルド」というプロセスをきちんと行うことを大切にしています。 前回の記事で、ハッシュ値を確認することで偽物を掴まされていないことを確認するプロセスがあることを説明したと思いますが、その一方で配信元がウイルスやマルウェアなどの悪意のあるコードを仕込んでいる場合は感知することはできません。これを防ぐための究極の方法は、ソースコードから直接ビルドすることです。公開されているソースコードからビルドすれば、ソースコードを確認することで悪意のあるコードが混入していないかを確認することができます。一方公開されているバイナリを直接インストールする方法の場合、悪意のあるコードが混入していることを確認する術はありません。元のソースコードが公開されていても、そのバイナリがそのソースコードからビルドされたことを確かめられないので無意味です。 このような理由で、GNU Guixはあらゆるパッケージを自分の手元でビルドすることを信条としています。もちろんサイズが大きいパッケージをたくさん使うような場合、全てビルドするのは大変な場合もあります。そのため、「このサーバーのビルドしたパッケージは信用できるので、ビルドする代わりにバイナリからインストールする」というのを実現する機能があります。この機能はSubstitutesと呼ばれています。デフォルトではGNUのサーバーだけが登録されています。詳しくは公式マニュアルをご覧ください。また、この機能はあくまでも「ビルド手順をパッケージ定義として示した上で、その手順と全く同一の手順を踏んでいるであろうバイナリを提供するサーバーを信用する」という機能であることに注意してください。ビルド手順の記述を省略するようなことはできません。そのへんに落ちているバイナリから直接インストールする機能は次回の記事で説明します。 ...
序文 GNU Guixでは、簡単にパッケージを作り、自分でそれを利用することができます。 GNU Guixでは、パッケージ定義群は「チャンネル」という名前がついています。 各々が自分だけのチャンネルを作り、それを公開するなりローカルに保持するなりし、Guixにそれを教えてあげることで、 そのチャンネルを経由してパッケージを利用することができるようになります。 ...