buildroot を使用して、ARM プラットフォームで実行される rootfs を作成しています。
ubuntu の apt-get のように、パッケージを簡単にインストールできるように、自分のプラットフォームにパッケージ マネージャーが必要です。
buildroot ビルドに簡単に追加できる opkg を見つけましたが、リポジトリの検索方法に関する情報が見つかりません。
また、これについて Web でいくつかのことを読んで、buildroot にパッケージ マネージャーが含まれていないことも読みました。opkg はパッケージマネージャーではありませんか? それとも、パッケージを取得するためのある種のフロントエンドですか?
パッケージマネージャーが何で構成されているのかよくわかりません。これに関する情報も見つかりません。
その種のマネージャーを実装するために本当に必要なもの、またはそのような情報をどこで見つけることができるかを誰かが説明できますか?
opkg はパッケージマネージャーではありませんか? それとも、パッケージを取得するためのある種のフロントエンドですか?
opkgはipkgに基づいています。のすべての機能を提供しようとしているようですapt-get。
その種のマネージャーを実装するために本当に必要なもの、またはそのような情報をどこで見つけることができるかを誰かが説明できますか?
パッケージ マネージャーは、さまざまな機能を提供します。それらが進化するにつれて、エンドユーザーにとって使いやすいさまざまなレイヤーが追加されました。一般に、それらは Linuxデスクトップまたはサーバー空間で始まり、組み込みシステムで使用するために移植されました。
いくつかの違い; 組み込みシステムは通常、シングルタスクです。パッケージ管理システムにより、ユーザーは何をインストールするかを選択できます。多くの場合、組み込みシステムでは、ユーザーがパッケージを選択できるようにしたくない場合があります。もちろん、それはアプリケーションに依存します。
一部のパッケージ管理機能、
RPM、dpkg、ipkgは通常、項目 1 ～ 4 のみを満たします。 Buildrootはこれさえしません。アイテム 1 だけが本当に関連しています。その理由は、Buildrootが更新されることのない固定システム用のソフトウェアをビルドすることを目的としているためです。デバイスにネットワーク接続や外部ストレージがない場合、ネットワーク更新とパッケージ移行を備えたファイル システムを使用しても意味がありません。また、Buildrootは最小限に抑えようとしますが、これらの追加機能にはコストがかかります。
LTIBは項目 1 ～ 3 を作成するシステムを提供しますが、ネットワーク ダウンロードは提供しません。また、そのままでは、 RPMサイズがかなり非効率的です。項目 4 は、典型的なdevelおよびdeployパッケージにつながります。ライブラリをビルドするには、依存パッケージをコンパイルするためのヘッダー ファイルが必要です。一般的なLTIB rpmには、すべてのヘッダー ファイルが含まれています。これらのヘッダーやmanページなどを除外したサブパッケージを作成するのは簡単な作業です。
OpenWrtはルーターには適していますが、グラフィック、サウンド、その他の機能が必要な場合は、パッケージが利用できない場合があります。さまざまなファイル システム ビルダーがありますが、さまざまなバリエーションがあるため、それぞれにコストとメリットがあります。多くの Linuxデスクトップおよびサーバー ディストリビューションがあるように、さまざまなパッケージ管理オプションを備えたルート ファイルシステムビルダーが多数あります。アプリケーションとシステムの強みを評価する必要があります。
アートレスノイズの回答は非常に便利だと思います。そこで、ここで別のことをカバーしようと思います。
まず、すべてのバイナリにはライブラリの依存関係があります。また、CentOS/RHEL/Oracle Linux のライブラリ ファイル名とディレクトリを見ると、Debian ベースのディストリビューションとはかなり異なっていることがわかります。つまり、あるバイナリから別のバイナリにコピーしても機能しません。
Debian "/bin/ls" を見ると:
ldd /bin/ls
linux-vdso.so.1 => (0x00007ffc269b0000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb8f3fa2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb8f3bd8000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb8f3968000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb8f3764000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb8f41c4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb8f3547000)
そしてOracleLinuxの「/bin/ls」:
ldd /bin/ls
linux-vdso.so.1 => (0x00007ffe8999b000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f9831e8e000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f9831c89000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007f9831a80000)
libc.so.6 => /lib64/libc.so.6 (0x00007f98316b3000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f9831451000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f983124d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f98320b5000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007f9831048000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9830e2c000)
私の知る限り、ディストリビューションには 2 つの大きなクラスがあります。Debian ベースと Redhat ベースです。(ipkg、opkg、dpkg はすべて debian で、yum/rpm は Redhat 用です)
また、パッケージ マネージャーは、ファイル システムの設計を理解し、関連するファイルを正しいディレクトリにコピーする必要があります。
Buildroot は、「OS」全体がいくつかの最小限のユーザー空間ファイルだけで構成されているか、デーモンが実行されていないほど無駄のないものにすることができます。方法を知っていれば、ほとんどすべてが構成可能です。
そして引用する: https://buildroot.org/downloads/manual/manual.html#faq-no-binary-packages
結論は、インストールされたファイルの追跡を追加して、パッケージが選択されていないときにそれらを削除したり、バイナリパッケージのリポジトリを生成したりすることは、確実に達成するのが非常に難しく、多くの複雑さを追加することです.
また、buildroot 設計のもう 1 つの利点は、常に最初から再構築されるため、相互に破損するバイナリ間ライブラリがないことです。
一方、ルート ファイルシステム イメージ全体を一度にアップグレードして完全なシステム アップグレードを行うことにより、組み込みシステムにデプロイされたイメージは、実際にテストおよび検証されたものであることが保証されます。