Управление пакетами Buildroot

Разве opkg не является менеджером пакетов? Или просто какой-то интерфейс для получения пакетов?

opkg основан на ipkg. Похоже, он пытается предоставить все возможности apt-get.

Может ли кто-нибудь объяснить, что на самом деле нужно для реализации такого менеджера или где найти такую ​​информацию?

Менеджеры пакетов предоставляют множество различных функций. По мере их развития добавлялись различные уровни удобства для конечного пользователя. Как правило, они запускались в пространстве рабочего стола или сервера Linux и были перенесены для использования во встроенных системах.

Некоторые отличия; встроенная система обычно однозадачная. Система управления пакетами позволяет пользователю выбирать то, что установлено. Часто встроенная система может не разрешать пользователю выбирать пакеты. Конечно, это зависит от приложений.

Некоторые функции управления пакетами,

1. Строительство и ямочный ремонт.
2. Зависимость пакетов и, следовательно, база данных пакетов.
3. Перенос пакетов.
4. Специализация пакета.
5. Автоматическая загрузка
6. Минимизируйте время загрузки / пропускную способность.

Rpm, dpkg, ipkg обычно выполняют только пункты 1–4. Buildroot даже этого не делает, действительно актуален только первый пункт. Причина в том, что Buildroot предназначен для создания программного обеспечения для фиксированной системы, которая никогда не будет обновляться. Нет смысла иметь файловую систему с сетевым обновлением и миграцией пакетов, если на устройстве нет сетевого подключения или внешнего хранилища. Кроме того, Buildroot старается быть минимальным, и за эти дополнительные функции приходится платить.

LTIB предоставляет систему для создания элементов 1–3, но не для загрузки по сети. Кроме того, из коробки он довольно неэффективен при размере об / мин. Пункт 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)

Насколько мне известно, существует два больших класса дистрибутивов: на основе Debian и на основе Redhat. (ipkg, opkg, dpkg - все это debian, а yum / rpm - для Redhat)

И менеджер пакетов должен понимать структуру файловой системы и копировать соответствующие файлы в правильные каталоги.

Buildroot можно построить настолько компактно, что вся ваша «ОС» будет состоять из нескольких файлов с минимальным пространством пользователя или без какого-либо запущенного демона. Практически все можно настроить, если вы знаете, как это сделать.

И процитирую: https://buildroot.org/downloads/manual/manual.html#faq-no-binary-packages

вывод состоит в том, что добавление отслеживания установленных файлов для их удаления, когда пакет не выбран, или для создания репозитория бинарных пакетов, - это то, чего очень трудно добиться с надежностью, и это добавит много сложностей.

И еще одно преимущество конструкции buildroot заключается в том, что нет межбинарных библиотек, которые могли бы повредить друг друга, поскольку они всегда перестраиваются с самого начала:

С другой стороны, при выполнении полного обновления системы путем одновременного обновления всего образа корневой файловой системы образ, развернутый во встроенной системе, гарантированно будет действительно тем, который был протестирован и подтвержден.