Buildroot package management

Question

I'm using buildroot to create a rootfs running on my ARM platform.

I'd like to have a package manager on my platform to easily install packages, like apt-get in ubuntu.

I found opkg, who can be simply added to the buildroot build, but I can't find any information about how to find a repository.

Also, reading some stuff on the web about this, I also read that buildroot didn't include a package manager. Isn't opkg a package manager? Or just some kind of frontend to fetch packages?

I don't really understand what a package manager consist of, and I don't find any information about this.

Could someone explain what is really needed to implement that kind of manager, or where to find such informations?

Answer 1

Isn't opkg a package manager? Or just some kind of frontend to fetch packages?

opkg is based on ipkg. It looks like it tries to provide all the features of apt-get.

Could someone explain what is really needed to implement that kind of manager, or where to find such information?

Package managers provide many different features. As they have evolved, different layers of ease for the end user has been added. Generally, they started in the Linux desktop or server space and have been ported for use in embedded systems.

Some differences; an embedded system is usually single tasked. A package management system allows the user to pick and choose what is installed. Often, an embedded system might not want to allow a user to pick and choose packages. Of course, it depends on the applications.

Some package management features,

1. Building and patching.
2. Package dependency and hence package database.
3. Package migration.
4. Package specialization.
5. Automated download
6. Minimize download time/bandwidth.

Rpm, dpkg, ipkg are typically only fulfilling items 1-4. Buildroot doesn't even do this, only item one is really relevant. The reason is that Buildroot is intended to build software for a fixed system that will never be updated. It doesn't make sense to have a file system with network update and package migration, it there is not network connection or external storage in the device. Also, Buildroot tries to be minimal and these extra features have a cost.

LTIB provide a system to create items 1-3, but not the network download. Also, out of the box, it is rather in-efficient in RPM size. Item 4, leads to typical devel and deploy packages. In order to build a library, you need header files to compile dependent packages. A typical LTIB rpm includes all the header files. It is an easy task to make sub-packages that exclude these headers and man pages, etc.

OpenWrt works well for routers, but if you need graphics, sound and other features the packages may not be available. There are various file system builders, but due to the amount of variations, each has costs and benefits. Just as there are many Linux desktop and server distributions, there are many root filesystem builder with different package management options. You have to evaluate the strengths for you application and system.

Answer 2

I find artless noise answer very useful. So I will try to cover something different here.

First all binaries have libraries dependencies. And if you look at the libraries filename and directories of CentOS/RHEL/Oracle Linux you will find it is quite different from that Debian-based distribution. Ie, if you copy the binaries from one to another, it will not work.

Looking at 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)

And OracleLinux's "/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)

As far as I am aware there are two big classes of distribution: Debian-based and Redhat-based. (ipkg, opkg, dpkg are all debian, and yum/rpm is for Redhat)

And the package manager is supposed to understand the filesystem design and copy the relelvant files into the correct directories.

Buildroot can be built so lean that your entire "OS" just consist of a few bare minimum userspace file, or without any running daemon. Almost everything is configurable, if you know how to.

And to quote: https://buildroot.org/downloads/manual/manual.html#faq-no-binary-packages

the conclusion is that adding tracking of installed files to remove them when the package is unselected, or to generate a repository of binary packages, is something that is very hard to achieve reliably and will add a lot of complexity.

And another advantage of buildroot design is that there is no inter-binaries libraries to corrupt each other since it is always rebuilt from start:

On the other hand, by doing complete system upgrades by upgrading the entire root filesystem image at once, the image deployed to the embedded system is guaranteed to really be the one that has been tested and validated.